Multiple Classloader instances being created.

[rammohan.natarajan]

We have an EAR containing 2 EJB modules and 1 WAR being migrated from Websphere 6.1 to JBoss EAP 5.0.

From the servlet, we are invoking code in each EJB module, to execute the following statement:

Thread.currentThread().getContextClassLoader();

We find that a different value of the classloader instance is being returned in each case.
org.jboss.util.loading.DelegatingClassLoader@16d1937 and
org.jboss.util.loading.DelegatingClassLoader@c2d5e9

Is this default behavior of JBoss?
Is there any configuration available such that both the modules are associated with the
same classloader?

P.S: In WebSphere 6.1, the same classloader instance is returned in each case.

[rammohan.natarajan]

Its been a while since I have had the chance to follow this up but here is an update:

The problem is in the map of 'global variables' maintained by commons-beanutils within
its ContextClassLoaderLocal instance.In a nutshell, the beanutils ContextClassLoaderLocal
ties variables to a classloader instance to ensure data isolation even if the variable is
referenced by multiple components running within a container.
http://commons.apache.org/beanutils/api/org/apache/commons/beanutils/ContextClassLoaderLocal.html

Here is the relevant code snippet from the get() method of
org.apache.commons.beanutils.ContextClassLoaderLocal :

            ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
            if (contextClassLoader != null) {
                
                Object value = valueByClassLoader.get(contextClassLoader);
                if ((value == null) 
                && !valueByClassLoader.containsKey(contextClassLoader)) {
                    value = initialValue();
                    valueByClassLoader.put(contextClassLoader, value);
                }
                return value;
            }

Our application uses commons-beanutils-1.8.3 to unmarshal custom XML. In doing so, the registration
of custom type converter for a particular bean happens within one EJB module while the
actual parsing of the input XML is in a different EJB module.

Under these circumstances, we find that the BeanUtilsBean instance corresponding to our bean
is maintained in the ContextClassLoaderLocal map against the classloader of the registration
EJB module. During the parsing process, this map is queried to retreive the same BeanUtilsBean
instance. This always fails since now the classloader instance is different.

As I have mentioned in my earlier post, the classloader instance is same when the application
runs in Websphere.

Is this a feature of WebSphere or a bug in JBoss? (or vice versa..I am not sure)
Is it possible to force JBoss to use the same classloader instance for all components within an EAR?

Please let me know if I am missing something or if additional details are required.

Thanks in advance.