4 Replies Latest reply on Jul 6, 2005 1:15 AM by stevenpeh

    Jboss class loader issue

    stevenpeh

      We're running into a very weird class loader problems.. we are currently using JBoss 4.0.2, basically the web class loader policy are the defaults ones,

      false
      false

      The server instance has an ear file deployed that is using spring framework. Inside we can see that it has a bunch of spring applicationContext.xml with various kinds of configurations/beans.

      Now we are trying to develop a web app deployed as an independant war file in JBoss. We are using a client jar from the ear application, inside it does not have any spring configs. However our web app is also using spring with our own applicationContext.xml. Now the problem is for some reason, when we deploy and use our web app, spring is loading the spring configs in the ear's ejb and overriding the ones in our web app!! How is this possible, doesn't the class loader settings above disable the unified class loader policy in JBoss, if we're not doing it right can someone please point out how to disable the unified class loader, the log snippet showing the overriding in spring is below.


      2005-06-30 14:52:24,546 INFO [org.springframework.beans.factory.support.DefaultListableBeanFactory] Overriding bean definition for bean 'com.foobar.arch.ApplicationConfiguration': replacing [Root bean with class [org.springframework.context.support.ClassPathXmlApplicationContext] defined in URL [jar:file:/C:/DevelopmentTools/JBoss/jboss-4.0.2/server/default/tmp/deploy/tmp2205springapp-exp.war/WEB-INF/lib/common.jar!/beanRefFactory.xml]] with [Root bean with class [org.springframework.context.support.ClassPathXmlApplicationContext] defined in URL [jar:file:/C:/DevelopmentTools/JBoss/jboss-4.0.2/server/default/tmp/deploy/tmp2203App.ear-contents/CommonEJBs.jar!/beanRefFactory.xml]]


      Notice that it is overiding the bean from our war file with the one in the ear file.... Anyone got any suggestions?

        • 1. Re: Jboss class loader issue
          stevenpeh

          whoops i guess the class loader config tags is not showing up, basically the Java2ClassLoadingCompliance and the UseJBossWebLoader is set to false

          • 2. Re: Jboss class loader issue
            stevenpeh

            Just an update, we noticed that the client jar (form the ear) that our web app is using perform spring init via beanRefFactory using the classpath url "classpath*:applicationConfig.xml". Now spring seems to look into all available class loaders and load whatever applicationConfig.xml it finds.

            But our question is, why does JBoss allow it to load from another ear's class loader? We already disabled the unified class loader, yet spring can still crossover from our war into another ear to look for configs (refer to the debug output above). Is this class loading behaviour by design? We've already looked at the wiki class loading article at http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration.

            The article doesnt shed any light on this, we've replicated this problem in both 4.0.1 and 4.0.2. Anyone has any comments as to whether this is as per designed or a bug? Appreciate any comments. Thanks.

            Cheers.

            • 3. Re: Jboss class loader issue
              starksm64
              • 4. Re: Jboss class loader issue
                stevenpeh

                Scott, we read through that post. Unfortunately, although it explains a lot of the UnifiedClassLoader, there is scarcely any information or use cases on WAR deployment, in fact, it is listed in the todo list of that wiki page. Unfortunately, we are still getting class loader problems in JBoss.

                As stated before, we already configured JBoss not to use the JBossWebLoader and also disabled the Java2ClassLoadingCompliance. However, when a library in our web app (the jar is in /WEB-INF/lib) try to load a class via reflection, JBoss is still returning the class loaded via the UnifiedClassLoader repository. We are pretty sure the class that is being reflected resides in a jar file our web apps /WEB-INF/lib. So why is JBoss still returning this class from the UCL repo instead of our web app's class loader?

                We added printout statements to the class doing the class loading and re-ran the execution. The following is the print out we get clearly indicating that the class is being loaded from the UCL and not from out we app's class loader.

                The first line shows the class we're trying to reflect, basically the same class as the class doing the reflection (dont ask us why, not our code). The second line shows the class that was returned and its class loader. The last line is just the class loader of the class doing the Class.forName call which is the web app class loader.


                 [STDOUT] class com.foobar.arch.security.cinterface.environment.EnvironmentFactory - getInstance : class [class com.foobar.arch.security.cinterface.environment.EnvironmentFactory]
                
                 [STDOUT] class com.foobar.arch.security.cinterface.environment.EnvironmentFactory - getInstance : class loader[org.jboss.mx.loading.UnifiedClassLoader3@1d2bb9f{ url=file:/C:/DevelopmentTools/JBoss/jboss-4.0.1/server/default/tmp/deploy/tmp2016OtherApp.ear ,addedOrder=41}]
                
                 [STDOUT] class com.foobar.arch.security.cinterface.environment.EnvironmentFactory - getInstance : this class loader[WebappClassLoader
                 delegate: false
                 repositories:
                 /WEB-INF/classes/
                ----------> Parent Classloader:
                java.net.FactoryURLClassLoader@1a12fe6
                


                Please, is there any configuration in JBoss to stop this problem? We are getting ClassCastException because of this class loading problem as Java is not recognizing the same class as being equal if they are not from the same class loader. Why is JBoss still looking into the UCL for the class even though the class is already in our web app and we already disabled the UCL for our web app?