Random Thoughts

Here is a small tip for eclipse users: running eclipse with -clean option once in a while can improve its startup time.

The clean option removes any cached data stored by eclipse runtime and forces cache reinitialization.

The heap size of the Jvm used by Maven (invoked via mvn.bat) can be changed using MAVEN_OPTS parameter at the OS level. For windows, this would be an environment variable.

Variable name: MAVEN_OPTS

Variable value: -Xmx512m

MDP (Message Driven Pojo) introduced in Spring 2.x offers a nice alternative to EJB’s Message Driven Beans.

package com.inflinx.test.mdp;

import javax.jms.Message;
import javax.jms.MessageListener;

public class TestMdp implements MessageListener
{
  public void onMessage(Message message)
  {
    System.out.println(message);
  }
}



Creating and configuring a MDP in Spring is a pretty straight forward process. The first step is to create a class that implements javax.jms.MessageListener interface.

Once the message listener is in place, the next step is to configure the MDP and related JMS components in Spring application context.  
<bean id=“testMdp” class=“com.inflinx.test.mdp.TestMdp” />
<jee:jndi-lookup id=“connectionFactory” jndi-name=“jms.testConnectionFactory” />
<jee:jndi-lookup id=“queue” jndi-name=“jms.testQueue” />
<bean id=“jmsTransactionManager” class=“org.springframework.jms.connection.JmsTransactionManager”>
<property name=“connectionFactory” ref=“connectionFactory” />


</bean>



<bean id=“jmsContainer” class=“org.springframework.jms.listener.DefaultMessageListenerContainer”>

<property name=“connectionFactory” ref=“connectionFactory”/>

<property name=“destination” ref=“queue”/>

<property name=“messageListener” ref=“testMdp” />

<property name=“transactionManager” ref=“jmsTransactionManager” />

</bean>

DBUnit is a very effective tool for testing persistence layer code. But before we can test any persistence code, we need to “seed” the database with some test data. This is where a dataset comes into picture.  I personally like to store this data in an XML file (XML dataset) and load it before a test is run. XML datasets can be easily created by exporting data from an existing database. Here are three simple steps for doing this:

1. Create a connection to the database. Using plain JDBC, here is what the code would look like:   
   
       Class.forName("com.mysql.jdbc.Driver");

       Connection jdbcConnection = DriverManager.getConnection("jdbc:mysql://localhost:3306/test","user","pwd");

       IDatabaseConnection connection = new DatabaseConnection(jdbcConnection);

2. Create a QueryDataSet object and add a query for extracting the data:
   
    QueryDataSet dataSet = new QueryDataSet(connection);
    dataSet.addTable("Person", "SELECT * FROM PERSON");
3. Save the extracted data into an XML file.
   
    FlatXmlDataSet.write(dataSet, new FileOutputStream("person.xml"));

Each XML element in the dataset created will correspond to a row in the table with the element name being the name of the table. Here is a portion of dataset generated:

<Person ID=”9″ First_NAME=”JOHN” LAST_NAME=”DOE”/>
<Person ID=”10″ First_NAME=”JUDY” MIDDLE_NAME=”B” LAST_NAME=”TEST”/>
<Person ID=”11″ First_NAME=”JANE” MIDDLE_NAME=”S” LAST_NAME=”DOE”/>

An interesting thing to keep in mind is that when DBUnit is used to load this dataset into a database, it would read the first element to figure out the table metadata. Now, if the first element does not have a column (MIDDLE_NAME in this case) included, it would make DBUnit ignore that column in all other elements. This behavior can be avoided by generating a DTD that contains table column information. This is done using the following code:

FlatDtdDataSet.write(dataSet, new FileOutputStream("person.dtd"));

Once the DTD is in place, it can be included in the dataset doctype declaration. In this example, it would look something like: <!DOCTYPE dataset SYSTEM “person.dtd”>

Putting it all in a single method:

public void generateDataSet() throws Exception
  {
    Class.forName("com.mysql.jdbc.Driver");
    Connection jdbcConnection = DriverManager.getConnection("jdbc:mysql://localhost:3306/test","root","mysql");
    IDatabaseConnection connection = new DatabaseConnection(jdbcConnection);
    
    QueryDataSet dataSet = new QueryDataSet(connection);
    dataSet.addTable("Person", "SELECT * FROM PERSON");
    
    FlatDtdDataSet.write(dataSet, new FileOutputStream("person.dtd"));
    FlatXmlDataSet.write(dataSet, new FileOutputStream("person.xml"));
    
    jdbcConnection.close();
  }

When running unit tests in a Spring-JPA application, I ran in to out of memory issue. The exact error was:

2008-05-01 14:43:32,944 DEBUG org.springframework.test.context.junit4.SpringMethodRoadie –
 Test method public void
…repository.ApplicationHibernateRepositoryTest.testFindApplication() threw exception:
      
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
Exception in thread “Thread-2” java.lang.OutOfMemoryError: Java heap space

The cause was that I had an entity with too many relationships to other entities.
A slight overlook fron my side caused all these relationships to be eagerly loaded (added to the fact that this is the default behavior for some associations in JPA).
I just went back and declared the relationships to be lazily loaded (using fetch=FetchType.LAZY) and the error just disappeared.

I believe it is possible to increase heap size for running Junit tests but in this case, I really didn’t need all the entities loaded eagerly.

JUnit 4 has some great features that makes unit testing way easier than before. Here are some tips for using JUnit 4:

1. In JUnit 3.x the test methods must start with a “test” prefix. JUnit 4 uses @Test annotation for identifying test methods. All my new tests now have the same name as the method being tested which I find is more readable.
2. JUnit 4 does not require the test class to extend TestCase class. Hence, to use assertXXX methods, you need to use the static methods available in Assert class. Java 5’s static import feature can make this usage very painless: import static org.junit.Assert.*;
3. JUnit 3.x provides setup and teardown methods for creating/destroying fixtures. JUnit 4 offers @Before and @After annotations that provide same functionality (remember that methods annotated with @Before and @After will run for every test method)
4. @BeforeClass and @AfterClass can only be used with static methods. These methods will run only once per class
5. A test can be ignored using @Ignore annotation
6. The expected attribute for @Test annotation can be used to verify exceptions thrown by a method (I remember using a Junit extension to achieve this behavior long time ago)

Hibernate’s migration guide mentions that WebLogic uses a different version of ANTLR causing this exception.

A work around for this problem (differnet from what Hibernate mentions) is to set the “prefer-web-inf-classes” element in weblogic.xml to true.

       <weblogic-web-app>
               ....
          <container-descriptor>
              <prefer-web-inf-classes>true</prefer-web-inf-classes>
         </container-descriptor>
               ....
       </weblogic-web-app>

I encountered this problem several months ago while running under WebLogic 8.x. Interestingly, it still exists in WebLogic 10.x server.

Update for Ear files: When deploying the application as an ear file on WebLogic 10.x server, add the following to weblogic-application.xml file:

   <prefer-application-packages>
		<package-name>antlr.*</package-name>
	</prefer-application-packages>

The weblogic-application.xml file should be under META-INF folder of the ear file.