1 Reply Latest reply on May 10, 2002 5:40 AM by Bavo De Ridder

    Ear classloading problems (struts, log4j)

    Bavo De Ridder Newbie


      I have a "simple" ear with the following layout:

      1) a few jar files in /library
      2) three war files

      Two of the war files use struts

      Boot.war: does not use struts, inits log4j
      AMC.war: uses struts (in /WEB-INF/lib)
      Struts.war: uses struts (in /WEB-INF/lib)

      The log4j.jar is in /library/log4j.jar

      When I deploy the application I get the following errors:

      Boot.war: JBoss (Tomcat) can't find the servlet used to init the application, it is in /WEB-INF/classes in the correct location
      AMC.war: runs perfectly, struts inits without problems
      Struts.war: JBoss (Tomcat) can't find any class in the struts.jar

      When I deploy the same ear to the SilverStream 3.7.4 application servers it runs perfectly without any problems.

      I also saw that JBoss uses log4j for logging events of the server itself. Although that is interesting, it seems that the logging of the deployed ear or war files also uses the JBoss global configuration. I think this is not good. I would like to set a logging configuration for each ear or war seperately.

      I have the same problem with the following versions of JBoss:

      JBoss 2.4.4 with Tomcat 4.0.1
      JBoss 3.0 beta
      JBoss 3.0 RC1

      All the above problems, the log4j issue and the fact that everything runs perfectly on a SilverStream 3.7.4 application server seems to indicate that JBoss has some serious classloader problems.

      As far as I can see, the ear, war en jar layout conforms to the J2EE standard.

      Any insights or tips on these issues ?

        • 1. Re: Ear classloading problems (struts, log4j)
          Bavo De Ridder Newbie


          After some experimenting, I finally found the problem. I knew of the MANIFEST.MF problem regarding the newline at the end of Class-Path entries. Since the mentioned SilverStream application server does not use the JDK classloaders but its own implementation, this "bug" did not occur.

          Adding a newline at the end of each Class-Path entry throughout the ear solved the problem.

          I still have the log4j problem however.

          Can it be turned off in 3.0 ?