EAR isolation problem

[armorris007]

I'm running JBoss 4.0.4 GA on JDK 1.5.

Having repackaged my application to work with an isolated EAR classloader, I have specified the following in my jboss-app.xml:

<jboss-app>
 <loader-repository>
 myapp:loader=myapp.ear
 <loader-repository-config>
 java2ParentDelegation=false
 </loader-repository-config>
 </loader-repository>
</jboss-app>

I also have ensured the following default values are used for the Tomcat classloading:

 <attribute name="Java2ClassLoadingCompliance">false</attribute>
 <attribute name="UseJBossWebLoader">false</attribute>

Despite this, I am finding that I am getting a classloader conflict relating to commons-http-cilent.jar. This JAR is packaged as part of my EAR application (loaded by the application's EAR classloader), however, it is also a server/lib library which is shipped as part of JBoss 4.0.4.

Contrary to what the documentation states here:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration

Isolation with Overriding Server Classes

Use the following constructs to enabled scoped class loading with the deployment classes overriding the server classes.

For jboss-app.xml:

<jboss-app>
 <loader-repository>
 com.example:loader=unique-archive-name
 <loader-repository-config>
 java2ParentDelegation=false
 </loader-repository-config>
 </loader-repository>
</jboss-app>

I am basically finding that the older commons-httpclient.jar as shipped with JBoss - is being used INSTEAD of the jar file I've shipped as part of my EAR.

The only way I've found to resolve this issue is by following the documentation for JBoss 3.2.3 - as specified on this page:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration

which states that a change to the "Isolation" attribute in the ear-deployer.xml file is needed.

I don't see why I need to make a system wide change - by changing this value IN ADDITION to specifying that I want an isolated EAR classloader by means of the instructions defined in jboss-app.xml.

As far as my application is concerned - I want an isolated classloader for my EAR - I do not want to affect the inter-operability of other EAR applications deployed within the server by having to change the system wide property defined in ear-deployer.xml.

Can anyone confirm that I have indeed found a bug? Or is this oddly by design?

Andy

[armorris007]

Contrary to my statement:

The only way I've found to resolve this issue is by following the documentation for JBoss 3.2.3 - as specified on this page:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration

changing the ear-deployer.xml DID NOT fix the class loading issue. A NoSuchMethod exception is still being thrown by my classes when trying to use a method which is part of the newer commons-httpclient.jar which is shipped with my EAR.

If I delete the commons-httpclient.jar from my server/default/lib dir - no exception is thrown - this proves that classloading hierarchies are causing this problem.

Anyone had similar experiences with trying to override server classes using their own version of the same libraries as shipped inside an EAR?

Many thanks,

Andy

[armorris007]

Ooops!

After further investigation (by looking at the the Classes loaded by the EAR class-loader using the JMX-CONSOLE) it looks like there was a problem with the manifest Class-path entry in the EJB-JAR file. A typo was stopping the commons-httpclient.jar being added to the EAR classpath.

The EAR shipped JAR files are now successfully overriding the server/default/lib classes ...

Apart from the infamous commons-logging.jar file which is causing me porting headaches - and refuses to be overriden

Apologies!

Andy