7 Replies Latest reply on Nov 19, 2002 4:52 PM by Gary Bisaga

    Ear Deployment Classpath problems

    Giles Paterson Newbie

      I'm trying to port an Ear from weblogic 6.1 to JBoss 3.0.4 and am running into a (I presume) classpath problem.

      The Ear file contains a couple of EJB Jar files, a couple of War files and a whole load of jars in a lib subdirectory:


      The EJB jars and war files all have a manifest file specifying the classpath (basically listing all of the jars in the lib directory)

      The application xml looks like this:







      When I try and run the application (by accessing one of the servlets specified in the dx_presentation.war), I get the following error message:

      java.lang.IllegalAccessError: try to access class org.jdom.ContentList from class org.jdom.Document

      Jdom is used extensively throughout this application and the jdom.jar is included in the lib directory of the Ear file, and is specified in the manifest classpath for each of the ejb jars and war files.

      Is this a class loader problem with JBoss? Is the servlet trying to access the jdom classes via the EJB classloader because the EJB was the first to access jdom?

      The Ear file deployed and ran fine under weblogic, so I know it should work, I'm just having problems getting to grips with JBoss.

      Does anyone have any suggestions to make?

        • 1. Re: Ear Deployment Classpath problems
          Elias Ross Master

          I've seen problems with classes accessing package-private methods in other classes. I think jdom.jar is also loaded by JBoss, so there may be some strange interactions taking place. (Class A is loaded by your EAR, class B is loaded by JBoss, and even though they are in the same package, cannot talk to each other.)

          Suggestion: (May or may not work)

          Construct a conf/jboss-app.xml, and include that along with your application.xml in your ear in the META-INF directory. Example XML file:


          • 2. Re: Ear Deployment Classpath problems
            Giles Paterson Newbie

            Thanks for the suggestion genman, unfortunately it has not solved my problem.

            So far the only solution I have found is to place the jdom.jar in the jboss-3.0.4\lib directory and explicitly add it to the JBOSS_CLASSPATH variable in the startup script, which is hardly ideal.

            Any other suggestions greatefully received.

            • 3. Re: Ear Deployment Classpath problems
              Giles Paterson Newbie

              Well, after trying genman's suggestion of a jboss-app.xml file in the ear with no success, I resorted to explicitly including the jdom.jar file in the JBOSS_CLASSPATH variable in the start up script.

              This allowed the application to progress further but I am now getting this error:

              java.lang.NoClassDefFoundError: javax/xml/transform/sax/SAXSource

              However, I am explicitly including the jaxp classes by packaging the xalan and xerces jaxp jars in the ear file.

              Since JBoss also makes use of xalan and xerces, I can only assume that this is another class loader problem.

              Am I doing something totally wrong in my ear packaging (despite the ear working under weblogic)? Or is there a problem with JBoss' classloading?

              All suggestions welcomed :-)

              • 4. Re: Ear Deployment Classpath problems
                Giles Paterson Newbie

                Well, I have made some progress, but I don't like the solution.

                Basically I have placed the jdom.jar into the jboss-3.0.4\server\default\lib directory. I then added a "-L jdom.jar" parameter to the shortcut I'm using to call run.bat (yes I'm running on a Windows 2000 server)

                This at least allows me to run my application but seems to me to be a messy solution as it means any other applications deployed on this server will need to use the same jdom version. In the current installation this shouldn't be a problem but who knows what the future may bring?

                BTW, the presence of a jdom-app.xml in the ear file has been totally irellevant in my instance. I don't know if there is a problem with my configuration or with JBoss 3.0.4 but class scoping using ears just doesn't seem to work.

                Well, that's it for now, unless anyone has any further suggestions? Now I just need to find out why JBoss is ignoring some of my servlet url-mappings, but I guess that's another forum.

                • 5. Re: Ear Deployment Classpath problems
                  Giles Paterson Newbie

                  In case anybody else is reading this conversation I'm having with myself, I have made more progress.

                  My previous solution of adding a -L jdom.jar startup parameter was only a partial success, in that I could proceed past the jdom NoClassDef errors but I then got other IllegalAccess exceptions from other third party jars.

                  In a fit of desperation, I extracted out the ear file (dx_all.ear) and placed the contents in a directory called dx_all.ear, and I removed the -L parameter from the startup script.

                  Lo and behold, everything worked. No exceptions or errors, just the application as it was intended to be :-)

                  Oh well, 3 days of hassle to find out that JBoss has a problem dealing with ear files.

                  A bit of experimentation has shown that class scoping doesn't work when your application is packaged in an ear file, but does work when the ear file is expanded out into a direcotry in the deploy directory. I proved this by removing the jboss-app.xml file from the dx_all.ear directory, and I encountered similar problems to when the application was in an ear file.

                  At least I have a solution for the time being, and I'll try and raise this problem with the JBoss powers-that-be and/or write a patch if I get time.

                  • 6. Re: Ear Deployment Classpath problems
                    Mikael Eriksson Novice

                    Well, I read it at least.

                    Just wanted to thank you for putting your solution into the forums and not just dropping it or writing something like "well I solved it now" :-)