As some of my friends know, I am a fan of Glassfish application server. I’ve used Tomcat also a lot, especially as many programs are bundled with Tomcat. This week I had my first more in depth experience with Jboss – as I had to figure out why a program I wrote failed miserably in Jboss.
I kicked myself for not testing during the development on Jboss too, but somehow I was under the impression that in this day and age different appservers would work without any glitches, but I was wrong. Of course it is not fair to complain so much as Jboss AS 5 is quite old, but at the same time it is important to realize that it is also the base version of the appserver in Jboss Enterprise Application Platform 5 – which is the currently sold and supported version of Jboss EAP. That is also the reason for my interest in to Jboss, as it was the selected production environment in a project I work in.
The program I was writing was really simple Spring application which combined Spring WebServices and Spring MVC together to provide an API to a custom database. Trying to understand what was going on was hard as stacktraces were really, really strange – and provided not much clues. Googling and previous memories lead me to find resources which helped me to pinpoint the situation into classloading mixups with xml-parser classes. Also Mikael Gueck gave good pointers into the right direction by mentioning jboss-classloading.xml.
The downside was that different resources provided contradicting information and software worked quite differently in different versions of Jboss AS 5 – and also differently on the production server on EAP 5. Eventually I just had to use trial and error and try different permutations of configurations to get to the point, where everything works.
So what did I learn?
I learned jboss-classloading.xml is a powerfull configuration file to be used in Jboss 5+-> appservers, providing capabilities to give isolation to your applications from other applications. Without it, there are possibilities that your classes will screw up something in another application or vice versa.
< classloading xmlns="urn:jboss:classloading:1.0"
< /classloading >
Above configuration – as far as I know – creates isolation to my application by providing it’s own domain, which means that classes from other loaders and domains will not conflict with it. Import-all and parent-first attributes might be redundant in this configuration.
However it seems that endorsed libraries in Jboss’s directories are not excluded with jboss-classloading.xml. As the my problem was with xml parsing libraries xerces etc., I tried and tried – but did not find a way to exclude them, hence I had to use a brute force method and exclude those jars from my war. Luckily I was using maven, and excluding jars from war was just a matter of adding configuration to the war-plugin.
At this stage I really thought that everything would already work.
Unfortunately it did not – and I felt devastated. As I sent SOAP message to my webservice everything worked fine and code worked perfectly, but the response body was empty. It worked on Glassfish, but failed on Jboss.
Last part of making everything fine required finding a forum post on Jboss community forums and putting that configuration into applicationContext.
<property name="messageFactory" >
And finally everything worked as I wanted!
Hopefully this post will help someone in the future.
Good resources that provided insights to me: