MiR: October 2008

I've settled into a routine this month that consists of daily building the latest SMX4 Kernel, NMR, and Features code from SVN and checking for any AIX specific errors. While nightly continuous integration testing works great for automating the discovery & identification of issues I find that this manual approach has been quite fruitful (When no issues are found I just move on to other JIRAs in the SMX4 projects). 

Common AIX issues I've seen this month include updates to the classpath and JVM security settings to work around IBM JDK differences in comparison to Sun, and some defensive coding around annotations.

Cheers,

More fun with IBM JDK on AIX

An issue that tends to turn up with various projects using Java's security mechanism is that the IBM JDK uses a different set of security providers than the reference Sun SDK. You'll know that your project is hitting this issue when a security related test fails due to a provider not found error (or similar message), even though the same test case passes on other platforms.

The manual solution is to edit the java.security file in $JAVA_HOME/jre/lib/security/java.security to contain the providers list in the order expected by Sun, however this may not be an option on your system (perhaps all java configuration files are locked down to read only permissions). In the case that you can't modify the java.security file directly you'll have to specify an alternate properties file for the JVM to use. This is as simple as passing the following JVM parameter to your test case launcher "-Djava.security.properties==
${path.to.ibm.jdk.security}", where ibm.jdk.security is your updated java.security file.

So how would one incorporate this into a maven based testing harness?

The below maven entry sets up a profile for IBM JDK and instructs the surefire test harness to use a provided java.security properties file. Please note that only when an IBM JDK is detected will the new java.security file be used.

<profiles>
<profile>
<id>ibmjdk</id>
<activation>
   <property>
       <name>java.vendor</name>
       <value>IBM Corporation</value>
   </property>
</activation>
<build>
 <plugins>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <configuration>
    <includes>
     <include>**/*Test*</include>
    </includes>
    <forkMode>pertest</forkMode>
    <argLine>
     -Djava.security.properties==
      ${path.to.test.resources}/ibm.jdk.security
    </argLine>
   </configuration>
  </plugin>
 </plugins>
</build>
</profile>
</profiles>

You may have noticed something a little strange about the JVM parameter, the use of the double equality is intentional - if you use a single equals (=) then it appends your specified property file to the default property file, the double equality forces your specified configuration to be used.

Cheers,

Relaxing Sunday afternoon with the IBM JDK and Servicemix 4.

I may have strange habits, nothing says 'relaxing Sunday afternoon' like diving into a project on an AIX system while hanging out in a cafe. 

Unlike many developers I actually enjoy my time with AIX, its a different environment that works well with my development style. Currently I'm attempting to resolve some testing issues that pop up when using IBM JDK to build & run unit tests of a Servicemix 4 Features SNAPSHOT - debugging this is a relatively simple process of identifying small differences in what comes packaged with Sun SDK vs the IBM JDK.

How does one know how to identify this kind of issue when working with Servicemix 4 on AIX?

Well the simplest way to determine this issue is reviewing the surefire test reports that are generated during a Servicemix 4 build. All test output is redirected to log files, inspecting these you'll most likely find that there will be a "<classname> not found error". If you know the jar that the particular class comes from then you can simply add the jar dependency to the pom file controlling the build of that component and retest. Regardless of if you know the class's parent jar or not it would be a good idea to open a report in SMX4's Jira to bring the issue to light.

What if the class/jar should already be available on the classpath?

In this case run the build with "mvn -X" to see exactly what libraries are being loaded. I tend to redirect the output from running maven with this flag to a file, then searching its contents. Sometimes you may need to reorder the loading order of jars due to naming conflicts, this however is rare (I've only seen that when working on Websphere based projects). A useful exercise when investigating this sort of issue is to build/test on another *nix platform to have a baseline to compare logs (personally I use Linux or Mac builds as a reference point). 

Once you've determined the solution to getting builds/unit tests running again then you'll want to try out your changes on a non-AIX system to verify a platform safe change, then submit a patch :)

Cheers