1 Reply Latest reply on Mar 30, 2011 3:31 AM by Rammohan Natarajan

    Multiple Classloader instances being created.

    Rammohan Natarajan Newbie

      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:




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


      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.

        • 1. Re: Multiple Classloader instances being created.
          Rammohan Natarajan Newbie

          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.


          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.