= Libraries adn Classloaders

Libraries

When deploying in jboss we need to ensure there are no library conflicts. Jboss had the Unified Classloader which made it nearly impossible to deploy different versions of a library in different modules. If this is still the default we should turn it off - it's a rich source of intermittent failures and the supposed performance gains are dubious in real life.

Web deployments may have work to be done. See http://community.jboss.org/wiki/useJBossWebClassLoaderinJBoss5.

Reading through the text it seems that by default web deployments will be isolated which is the desirable case. If not some or all of th efollowing may be required.

Ear files may still be different.

I believe the easiest approach for jboss 5+ is to edit default/deployers/ear-deployer-jboss-beans.xml We have this:

   <bean name="EARClassLoaderDeployer" class="org.jboss.deployment.EarClassLoaderDeployer">
      <!-- A flag indicating if ear deployments should have their own scoped
         class loader to isolate their classes from other deployments.
      -->      
      <property name="isolated">false</property>
   </bean>

Set that to true.

In addition in conf/jboss-service.xml, we need this

      <!-- The call by value mode. true if all lookups are unmarshalled using
         the caller's TCL, false if in VM lookups return the value by reference.
      -->
      <attribute name="CallByValue">true</attribute>

Other perhaps out of date information.

The (fairly old) article at http://community.jboss.org/wiki/ClassLoadingConfiguration gives some information: in the jboss-app.xml for the ear file add something like the following (we may already be doing this)

<jboss-app>
   <loader-repository> 
     org.bedework:archive=bedework-calendar 
   </loader-repository> 
</jboss-app>

For standalone war files, in the jboss-web.xml we need (for jboss 4.2.1+

<jboss-web>
   <loader-repository> 
     org.bedework:archive=tzsvr 
   </loader-repository> 
</jboss-web> 

The loader-repository element must appear in the correct place. check the respective dtd.

For jboss-service.xml files the loader-repository element must appear as the first element within the service element.

Note that adding the term

<loader-repository-config>java2ParentDelegation=false</loader-repository-config> 

might be better as it allows the deployed application to override server classes, for example - with a web application:

<jboss-web>
  <loader-repository> 
    org.bedework:archive=tzsvr 
    <loader-repository-config>java2ParentDelegation=false</loader-repository-config> 
  </loader-repository> 
</jboss-web> 

causes classes to be loaded in the order:

• WEB-INF/lib
• server/default/lib (for default config)
• from the tomcat deployment

We should also remove any log4j configurations that might conflict