Finally, I noticed that the Maven build (maven-dependency-plugin:copy-dependencies) added more external jars in the classpath than was previously in the Ant build. It contained gnujaxp which was added transitively by jfreechart, also used by the application. By excluding gnujaxp, the Axis call finally worked as expected. I guess the moral of the story is: when getting completely unexpected behavior, there is a good chance that it is dependency conflicts. Looking carefully at the Maven copied dependencies could reveal any unnecessary dependencies. It would be useful to know which part of the code uses which dependencies. In any case, I wonder how many implementation of jaxp are out there.

Since I fixed that memory leak, I haven’t had a chance to look into profilers and am just lately wondering about to do some performance profiling. The realtime graphs in JProbe has an advantage over cheaper options (no pricing on the website, since it’s really for big companies who care to profile).

What is your experience with profilers?

As part of a huge refactoring effort, I’m working with the TestNG, Maven, Netbeans. Not surprisingly, everything has not been a breeze. So I put together these steps to set up test development using TestNG and Maven, and debugging with any IDE. In fact, TestNG can be easily replaced by JUnit here. It’s more about getting around the Maven build life cycle during test development.

1) Skipping the Maven test phase until test development is complete

The first problem I encountered was that the jars get created at the install phase near the end of the Maven build life cycle, which means that if the tests fail, the jar never gets created. Apparently, this is not meant for test development. The solution is to turn off the test phase by setting skip to true in the configuration of the surefire plugin, until all tests pass and can be used for automated testing.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
<suiteXmlFiles>
<suiteXmlFile>src/test/config/testng.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>

2) Copying all dependencies to target/lib

This is usually done for any jar that is an executable (contains a main method), so that you can reference the dependencies easily from within the jar manifest.

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>dependency-maven-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>

3) Referencing dependencies in the jar manifest

The following creates a manifest in the jar with references to all the dependencies previously copied to lib. Note that the classPrefix is lib.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<jarName>myapp</jarName>
<archive>
<manifest>
<mainClass>com.mycompany.MyApp</mainClass>
<addClasspath>true</addClasspath>
<classpathPrefix>lib</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>

4) Packaging the tests

Next, I add a Maven goal to produce a jar of the test sources.

mvn clean install jar:test-jar

This produces a jar (myapp-tests.jar) in your target directory next to your normal jar (myapp.jar)

5) Running the tests with TestNG

Then, I run the tests on the command line using TestNG instead of via Maven.

java -cp ./target/myapp.jar;./target/myapp-tests.jar; org.testng.TestNG ./src/test/config/testng.xml

I put the testng.xml in the config directory instead of resources because it is a runtime configuration and does not need to be part of the jar. Everything in the resources directory gets added to the jar.

6) Debugging the tests
Debugging the tests is simple.

java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,address=8888 -cp ./target/myapp.jar;./target/myapp-tests.jar; org.testng.TestNG ./src/test/config/testng.xml

From your IDE, attach your debugger to port 8888 using a SocketAttach to attach to an external program.

Current method:

String currentMethod() {
return Thread.currentThread().getStackTrace()[3].getMethodName();
}

The number in the stack trace changes depending on how far down you bury this call.
Really handy for unit testing or debug logging (remember to wrap debug logging with logger.isDebug()).