Anyway to use my own optional libraries with a deployed JAR?

[asack]

I have jar that is shared across EARs. It uses dom4j with XPath, i.e. needs jaxen. I put Class-Path entries to add my own packaged versions but I believe due to the way the UCL works, it still picking them up from $JBOSS_HOME/lib/dom4j.jar since this jar gets loaded first at startup.

Is there anyway around this? I thought java2Parent delegation is on a per EAR basis, not JARs.

I'm trying to avoid if possible from replacing the dom4j.jar file and adding extra libraries in server/default/lib which have scope across everything (its not that bad, but if I can avoid it, I want to).

Any comments come much appreciated!

[asack]

Anybody?

[130g]

I am having the exact same problem. I am trying to upgrade from 4.0.1 to 4.0.3 but this is kinda holding me back.
Anyone has a solution for this?

[asack]

"130g" wrote:
I am having the exact same problem. I am trying to upgrade from 4.0.1 to 4.0.3 but this is kinda holding me back.
Anyone has a solution for this?

See technically dom4j is a platform required jar and as such this behavior really doesn't violate the J2EE spec. With that said, this behavior is still kinda sucka.

For J2EE 5 we need the following ordering:

1) Grab any optional libraries out of lib or whatever lib directory is defined in the optional applicaiton.xml file first (regardless of java2Parent delegation, if anything this should be turned off by default)

2) If the class is not there, check the parent classloader which should be JARs found in the deploy directory (global scope across deployments), server/*/lib, and then lib.

3) If not there go to the boostrap classloader (JRE)

Based on the WIKI, I believe to use my own dom4j today (without replacing the platform one which I'm doing now), I would have to wrap this in an EAR, add a Manfiest entry in the jar within the EAR, and turn java2ParentDelegation off. This should prevent the classloader from finding the already cached /lib/dom4.jar first. But this doesn't help me because with EAR isolation on I can't share that jar file across multiple EARs.

I maybe missing something and perhaps this is pilot error on my part, but to me, the classloading scheme currently in place is not right (too many JBoss specific options to make classloading behavior what it probably should be by default).

[antifun]

I am running up against this issue as well. Did you determine if this is the only workaround for jboss 4.0.3?

With classloader logging and JMX inspection, I can see that it will load a dom4j jar stashed in the WAR (only, however, if it appears in the manifest class-path). However it seems to stubbornly insist on using the dom4j classes from the NoAttributeClassLoader (that is, the bootstrap one).

Very annoying. You would NEVER want to package a jar inside an application only to have it superseded by one in the app server...

-m

[130g]

I did not find a work-a-round that I felt comfortable with, so we, and our customers, will not upgrade to the new version of JBoss. Instead we will be moving on to Geronimo.
I have for a long time been very unhappy with the less than logical class loader system in JBoss, but this was the last straw that convinced me that the JBoss people really have THE worst class loader system of all times.