Classloading: Using isolation and accessing global libraries
karink Jan 18, 2005 4:43 AMHello
I have the following requirements regarding class loading in JBoss/Tomcat
Firstly, all the deployment units should be isolated from each other, and
have the possibility to override classes of the parent classloader
(as described in the "Isolation with Overriding" feature in
http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration)).
Secondly, some libraries should be globally accessible. This means they
are installed on the machine in one directory and all applications can
use them.
I constructed the following test application:
In my example I would like to have an EAR file which contains two WAR-files.
The classes from the WAR-file should be first loaded from the classes directory
of the WAR-file then from the lib and last from the parent class loader.
For the sake of this example the two war files contain exactly the same
servlet which invoke a class that can determine its own codesource.
This class is deployed in a jar file the WEB-INF/lib file of each War-file.
The jar file is called jpi-jboss-iv-classloadertest.jar.
The servlet than just reports a string from where the jar file is loaded.
for example
[STDOUT] CodeSource = (file:/C:/jboss/4.0/server/test/tmp/deploy/tmp52670my.sar-contents/first.war/WEB-INF/lib/jpi-jboss-iv-classloadertest.jar <no certificates>)
This way I can see from which Jar file the class is loaded.
My first approach was following the solution described in the WIKI mentioned
above. So each WAR-file does contain a jboss-web.xml file which configure
a loader-repository in this way
jboss-web.xml of first.war
<class-loading java2ClassLoadingCompliance="false"> <loader-repository> com.winterthur.jackpot.karin:loader=first.war <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </class-loading>
jboss-web.xml of second.war
<class-loading java2ClassLoadingCompliance="false"> <loader-repository> com.winterthur.jackpot.karin2:loader=second.war <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </class-loading>
Because I'd like to access those global libraries I build up a SAR-file
that contains a jboss-service.xml where I defined a classpath including
my global accessible libraries. The SAR-file does contain the EAR-file
mentioned above.
(which contains the two WAR-files).
The jboss-service.xml file looks like this:
<server> <classpath codebase="file:/C:/common/lib/" archives="mycommon.jar"/> </server>
The flag "UseJBossWebLoader" and the flag "Java2ClassLoadingCompliance"
in the file jboss-service.xml of Tomcat are set to true.
To test the isolation between the JBoss and th application I also deployed
the jpi-jboss-iv-classloadertest.jar to the server/lib directory of Jboss.
The effect of this configuration was that the class was not loaded from the
War file but from the server/lib directory of JBoss.
In my next trial I set the flag "Java2ClassLoadingCompliance"
in the file jboss-service.xml of Tomcat to false, but this has the same effect.
Now I defined the loader-repository in the jboss-service.xml file, then the
class was loaded from always the same WAR-file (this was what I expected, but not
the effect I wish to have, because I'd like to isolate the different
WAR-files from each other).
At the end I came up with a configuration that seems to work fine,
but as it does not correspond to the recommendation in the WIKI,
I would ask you to review this. Possibly there is another better solution,
than this.
Ok, here is the configuration:
I did not define any loader repositories (not in the jboss-service.xml
file and not in the jboss-web.xml file), but I set the flag "UseJBossWebLoader" and the flag "Java2ClassLoadingCompliance"
in the file jboss-service.xml of Tomcat are set to false.
This way the jpi-jboss-iv-classloadertest.jar is loaded from the WAR file in use (so separation of the
WARs from each other is reached), also the mycommon.jar was found.
Regards Karin
P.S.:
I use JBoss 4.0.1 (build: CVSTag=JBoss_4_0_1 date=200412230944