Close
 

JBoss application server tutorials

Solving JBoss 5 classloading issues

 
A common issue for many developers is how to solve Classloader issues, which are usually masked by strange errors like ClassCastException. Let's see a concrete example, how to solve this issue for Web applications.
The Classloading problem boils down to the fact that you have added in your deployment unit (Ex. WAR file) some libraries which are already referenced by JBoss in your server library repository.

The simplest way to fix this problem, is to remove the libraries under WEB-INF/lib that you have in your JBoss server installation ( server/xxx/lib for JBoss 4 , or common/lib for JBoss 5).
However it can be that you need a more recent (or earlier) release of your library so you want to keep your library in WEB-INF/lib.

In this article we have shown how to solve a few issues with Classloading with JBoss 4
JBoss 5 adds the concepts of custom meta data files, one of which is jboss-classloading.xml which let you define exactly how the war classloader is constructed.
Let's see an example. Supposing you are using a different release of the Xercers parser to use SAX in your JBoss applications. Here's your application structure:

 

C:\mywar.war
└───WEB-INF
    │     web.xml
    │
    └───lib
              xercesImpl.jar
If you try to deploy your application as it is, JBoss AS will complain:

18:10:45,353 INFO  [TomcatDeployment] deploy, ctxPath=/mywar.war
18:10:45,462 ERROR [JBossContextConfig] XML error parsing: context.xml
org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser


Now add the following jboss-classloading.xml to your WEB-INF folder:
<classloading xmlns="urn:jboss:classloading:1.0" 
              name="mywar.war" 
              domain="mywar_domain">

              parent-domain="Ignored"
 
              export-all="NON_EMPTY" 
              import-all="true"> 
</classloading>

In this case, we put the war's classloader in the "mywar_domain" which is shared with all other applications that don't define their own domain. We also choose to look at all other classes exported by other applications "import-all" and to expose all our classes to other classes "export-all".


What we get when we deploy this file, is that the Web application classloader will act as top-level Classloader so there will be no conflict with the same classes in the server's library.

The application structure with the jboss-classloading.xml turns to.


C:\mywar.war
└───WEB-INF
    │   jboss-classloading.xml
    │   web.xml
    │
    └───lib
            xercesImpl.jar
 

{fcomment}<

Solving JBoss 5 classloading issues
Francesco Google+