-
1. Re: Jboss class loader issue
stevenpeh Jun 30, 2005 3:03 AM (in response to 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 Jun 30, 2005 8:49 PM (in response to 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. -
4. Re: Jboss class loader issue
stevenpeh Jul 6, 2005 1:15 AM (in response to 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?