We are migrating a host of services from JBoss 4.0.5 to JBoss 5.1.0.CR1 (we attempted to use 5.0.1.GA but encountered a bug with using double values as parameters to EJB3 Beans which is fixed in 5.1.0). We have had to make a number of minor modifications to our services (mostly XML configuration changes), but we have migrated a good number of services already. However, we have just encountered an issue that we have not been able to find a good solution for yet.
The gist of the issue is that it appears that the classloader isolation for one of our .ear files is not fully working. We are using JMS via JBoss Messaging to deliver messages on a Topic to interested applications. One of these recipient applications lives within the same JBoss server as the service that publishes the messages (it very well might not in our production environments, but for development purposes it does). The recipient application uses a set of internally developed libraries to connect and receive messages from the topic (which worked properly in 4.0.5 and continues to work properly for my test clients that operate outside of JBoss). When I run the client process (in JBoss5.1.0) through the debugger I can see that the payload of the ObjectMessage received is the same class, but has come from the ClassLoader of the publishers .ear file.
The publisher has the following XML in the jboss-app.xml file:
<?xml version="1.0"?> <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD Java EE Application 5.0//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_5_0.dtd"> <jboss-app> <loader-repository> StargateServer:loader=StargateServer.ear <loader-repository-config> java2ParentDelegation=true </loader-repository-config> </loader-repository> </jboss-app>
I have tried it without the java2ParentDelegation and with the delegation set to false, but no combination changes this behavior. The client in question lives within a .war file deployed within a .ear file. In early testing I had isolated the .war file to the point that it could connect to a JBoss 4.0.5 server using the JBoss 4.0.5 client libraries (as none of our services were yet ported to JBoss5), but even that does not seem to prevent the pollution from occurring (and if I understand correctly the issue is that the publisher is somehow exporting the class despite having it's own class loader domain and isolation of the recipient is a separate issue).
The exact same set of XML in the jboss-app.xml files (DOCTYPE aside)used to work under 4.0.5 and I cannot find anything indicating how I should modify these files for JBoss5 to resolve the issue. I have seen reference to a "jboss-classloading.xml" file and a JIRA indicating that it should have documentation, but I'm not sure if it is something I need to use (and less sure how to use it if I should).
Of particular interest, the client initially synchronizes with the remote service (within the same JBoss5 AS) at the point of subscribing to the topic and receives a generified List of the exact same Objects that are used as the payload of the ObjectMessages. This List of Objects is obtained via a Stateless EJB exposed by the publisher and is not polluted (the Object class was loaded using the ClassLoader of the client). This would seem to imply that the issue is related to the fact that the Objects are being exchanged via JMS (JBoss Messaging). Is there configuration in the destination-service that controls this?
This seems somewhat similar to a couple of JIRA tickets (e.g. https://jira.jboss.org/jira/browse/JBMESSAGING-1277), but they have been closed and the fix versions cited are several back from the messaging implementation included in JBoss 5.1.0.CR1 (1.4.3).
We are using isolation because we don't have a guarantee about our deployment environments and we may need to have multiple client applications connecting to different versions of our services within the same JBoss instance, however we do share common database drivers and the JBoss libraries.
Any advice would be appreciated.
Thanks in advance,