The 2.4 and 3.0 classloaders are different.
The 3.0 version should be a lot easier to use.
Some general points applicable to both.
1) Don't put anything in JBOSS_CLASSPATH, it will only be
able to see other jars in JBOSS_CLASSPATH during class
2) jboss/lib jars are added using MANIFEST.MF in run.jar
so adding anything there won't work
3) jboss/lib/ext is for utility jars you wouldn't expect
to change, everything except the first two can see these
classes (see jsps below)
4) jboss/deploy/YourApp.ear this is the preferred place
for helper jars that need hot deployment (see jsps below)
5) WEB-INF/lib I think this is only useful for wars that
need helper classes (see jsps below)
There seems to be some problem with the classpath for
jsp compilation. It doesn't use the classloader.
Instead, it uses WEB-INF/classes and WEB-INF/lib
plus the web-container's classes.
I've seen it mentioned that it also uses the
META-INF/MANIFEST.MF classpath element on some Web
This can cause problems for jars in the ear and
makes it impossible to reference lib/ext classes.
WARNING: I don't use JSP. This is all stuff I've
picked up from other posts.
On your final point. If a class is loaded from a
different classloader it is a different class, regardless
of timestamp or bytecode.
Thanks for the reply.
My interest was for 3.0.0.
When you say "JSP compilation", is it limited to that or might this problem be bleeding over into the runtime classpath for any WAR application ?
The case I tried was installing Axis by creating an axis.war from their webapps/axis directory (which contains an index.html and WEB-INF with lib containing several JARs). This worked fine. I then removed the JARs from WEB-INF/lib, recreated the axis.war without them, added all of the JARs to $JBOSS_DIST/lib/ext, and restarted JBoss. After that, attempts to use the WAR failed because classes in the JARs couldn't be seen.
This was the jboss-3.0.0alpha download version. I'll try it with DR1 as soon as I can get a CVS version to work.
I guess the classloader question boils down to whether JBoss is using different classloaders for different EARs and WARs. It seems like it would have to in order to keep different versions of identically-named classes separate (e.g. people packaging their own log4j.jar), but the WebSphere article mentioned (I think) some capability to tell the server to use a separate classloader for each app, or a single classloader for all of them.
I'm pretty new at this, but it seems like there is an incredible potential for having (N where N is large) versions of the identical class loaded in memory.
I don't know how Axis deals with the classloader,
but I know there's been a fair bit of work done on it
For DR1, I think this will work.
Each application/jar gets it's own classloader.
This classloader is also added to a global pool.
If the class cannot be found in its own classloader,
it uses the global pool to load the class.
I've not delved too deeply into the code yet, so
don't ask me any complicated questions :-)
CVS is getting close. It should be branching for the DR1
release on Friday???