Solving JBoss 5 classloading issues

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active
 
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}


Advertisement

Related articles available on mastertheboss.com

JBoss MBeans POJO

JMX MBean services are the core building blocks of the JBoss Appl

How to a dump of JNDI tree with JMX console ?

#2 JBoss Howto. This is the recipe of the day

How to configure JBoss to bind to a different IP ?

  If you want to change the jboss.bind.address property use the 

How to shut down JBoss from remote ?

JBoss recipe of the day

How to create multiple instances of an Mbean?

  Supposing you need two instances of an MBean, let's say one fo

JBoss classloader issues

By default JBoss (prior to version 3.2) uses a flat class loading