Cash Advance Cash Advance
When I unit test my Data Access Layer (DAL), I really want to hit the database to ensure that I am executing correct SQL Queries against correct database schema. I have been using embedded (in-memory) databases like HSQL, H2 and Derby to unit test my Data Access Layer code.
Thanks to Spring 3, embedding databases in my unit tests is extremely straightforward. I just have to include the following lines in my application context:
<jdbc:embedded-database id="dataSource"> <jdbc:script location="classpath:schema.sql"/> <jdbc:script location="classpath:test-data.sql"/> </jdbc:embedded-database>
There are couple of problems with this approach though:
I can use Hibernate to generate and populate database specific schema automatically. But what if I am not using Hibernate (like in my recent project)? Ideally, I would like to solve these issues by using the same database that I have in my Production environment – MySQL. A Java utility called MySQL Connector/MXJ can be used to address these problems.
Maven provides many archetypes to generate various types of project skeletons. This blog post explains how to create a custom archetype that is tailor-made for your own situation. We will create an archetype for the Struts2 application.
My current development environment includes:
You need to have a starter project from which new archetype can be created. We can start with the Struts2 application created in the blog post Starting Struts2 web application development (using Maven2 and Eclipse) to create a custom archetype for Struts2 based applications. You can download the zipped source code for this project here.
Recently I had to implement a service that involved multiple nodes in a cluster to aggregate the data for certain period of time and report it back to the central server. The central server, then aggregated results provided by all the nodes in the cluster. This required all the nodes to align properly when reporting the aggregate data to the central.
For example, if the system was configured to aggregate data for 10 minutes, each node in the cluster was expected to send the aggregate data, every 10th minute beginning at the top of the hour. In this case, the central server was expecting data from all the nodes at 10:00 am, 10:10 am, 10:20 am, 10:30 am and so on. The node started at 10:05:15 am was expected to report its aggregate data at 10:10:00 am and every 10th minutes after that (instead of 10 minutes after the node is started and every 10 minutes after that).