Troubleshooting Java classloader or class loading issues -- JBoss example
Every Java developer faces the following issue from time to time.
"I thought that I was using my application package version of a library but apparently my application server (e.g. Weblogic, JBoss) has already loaded an older version of this-library-issue"
These issues normally arise when there are certain classes which are packaged along with Application Server as part of common libraries and the same set of classes are also present in our Application package as well (normally inside WEB-INF/lib folder of the application). The reasons for the problem lies with how the class loading works in any Application Server. Different Application Servers provide different mechanisms to deal with this problem. We have already looked at how to deal with this in Weblogic application server.
In JBoss 4.x versions, you need to turn off the PARENT_FIRST delegation mode in its jboss-web.xml descriptor file.
In JBoss 5 on wards, you need to have a jboss-classloading.xml in my_app.ear/META-INF as shown below
JBoss AS 7 follows a real modular approach deprecating all earlier approaches. The server bootstrap libraries are now located at the root of the application server. The jboss-deployment-structure.xml needs to be placed within the META-INF folder of the EAR or inside WEB-INF of your war file.
You can apply exclusions
This is only a general discussion. Please refer to the relevant JBoss documentation for more options and appropriate solutions.
In JBoss 4.x versions, you need to turn off the PARENT_FIRST delegation mode in its jboss-web.xml descriptor file.
<jboss-web> <!-- Sets the isolation scope for the WAR. We are now using a parent LAST policy for the war classloader. Meaning that classes/jars in the war take precedence over those provided by the EAr & App Server. --> <loader-repository> maya.macquarie.com:loader=my-webservices.war <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </jboss-web>
In JBoss 5 on wards, you need to have a jboss-classloading.xml in my_app.ear/META-INF as shown below
<classloading xmlns="urn:jboss:classloading:1.0" domain="my_app.ear" export-all="NON_EMPTY" import-all="true" parent-first="false"> </classloading>
- by setting the domain, we are specifing that the my_app.ear application participate in its own domain my_app.ear.
- by setting parent-first to false, we are essentially declaring that EARs classes be preferred over JBoss’s
JBoss AS 7 follows a real modular approach deprecating all earlier approaches. The server bootstrap libraries are now located at the root of the application server. The jboss-deployment-structure.xml needs to be placed within the META-INF folder of the EAR or inside WEB-INF of your war file.
<jboss-deployment-structure> <sub-deployment name="my_app.war"> <dependencies> <module name="org.apache.log4j" /> </dependencies> </sub-deployment> </jboss-deployment-structure>
You can apply exclusions
<jboss-deployment-structure> <deployment> <exclusions> <module name="javax.faces.api" /> <module name="com.sun.jsf-impl" /> </exclusions> <dependencies> <module name="javax.faces.api" slot="2.0"/> <module name="com.sun.jsf-impl" slot="2.0"/> </dependencies> </deployment> </jboss-deployment-structure>
This is only a general discussion. Please refer to the relevant JBoss documentation for more options and appropriate solutions.
Labels: Class loader, JBoss
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home