3 Replies Latest reply on Sep 20, 2004 7:05 PM by starksm64

    Classloader problems between 3.2.5 and 4.0.0

      I don't have any trouble under 3.2.5.

      With 4.0, classloader isolation seems broken. I can specify a setting for my MBean, but a jar in a previously loaded sar is used instead. I can package my application into a sar (before all jars were tossed in the deploy dir), but have the same problem with a previously loaded jar being used instead of my jar.

      This also causes problems with JBoss sars. For example now the commons-logging packages in my sar are used instead of the ones that ship with the Tomcat sar, causing problems with Tomcat on shutdown.

      Is this a bug or am I doing something wrong?

      Thanks,
      Jim

        • 1. Re: Classloader problems between 3.2.5 and 4.0.0
          starksm64

          A bug report with an explicit usecase or testcase is needed. The default config uses different default scoping on ears, jndi and wars. The standard config is equivalent to the 3.2.5 default config in terms of the class loading behavior.

          • 2. Re: Classloader problems between 3.2.5 and 4.0.0

            I still have the problem, even with standard config. I'm sorry if this isn't the proper place for a complete bug report. If you need a downloadable example, please point me to the proper place and I'll file a bug and add an attachment (assume you use bugzilla).

            Description:

            Classes seem to be loaded, first come first served, and aren't overridden based on SAR.

            SAR S1:
            META-INF/jboss-service.xml
            Axis.jar
            MBean1.jar

            SAR S2:
            META-INF/jboss-service.xml
            Axis.jar
            MBean2.jar

            S1 and S2 contain different versions of Axis. S1 and S2 do not have MBeans in common. S1 is loaded before S2. The S1 version of the Axis classes are used within calls to S2's MBean. This is causing NoSuchMethodErrors because of differences in sigs between Axis versions.

            This should be easily reproducable by a developer. Likewise in my case I use a different version of commons-logging. My SAR contains the commons logging jars, and is loaded before JBoss' jbossweb-tomcat50.sar. This causes the following error on shutdown:

            15:30:19,830 ERROR [HostConfig] Error undeploying web application at context path
            java.lang.NoSuchMethodError: org.apache.commons.logging.LogFactory.release(Ljava/lang/ClassLoader;)V
            at org.jboss.web.tomcat.tc5.WebCtxLoader.stop(WebCtxLoader.java:118)
            at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4546)
            at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:952)
            at org.apache.catalina.core.StandardHostDeployer.remove(StandardHostDeployer.java:670)
            at org.apache.catalina.core.StandardHost.remove(StandardHost.java:946)
            at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1028)
            at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1005)
            at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:351)
            ...

            If you need more information to verify this, let me know what to do and where to go to do it.

            Thanks,
            Jim

            • 3. Re: Classloader problems between 3.2.5 and 4.0.0
              starksm64