5 Replies Latest reply on May 2, 2003 5:00 AM by pants

    3.2.0 Classloader issue

    pants

      Hi, I've just upgraded from 3.0.6 to 3.2.0 and the classloader behaviour appears to have changed.

      I have deployed 2 ears (A.ear and B.ear). Both contain a copy of a common shared jar (X.jar). When I try and call a method on one of the ears I get a LinkageError on a class in X.jar:

      java.lang.LinkageError: duplicate class definition: com/a/b/c/MyClass

      This is a pain, but makes sense I guess, the class IS in Jboss twice.

      Anyway, I tried defining a loader-repository entry for the 2 ears so they are loaded in 2 different classloaders, but since they need to communicate I keep getting ClassCastExceptions when I pass classes from X.jar between the 2 ears.

      This wasn't an issue in 3.0.6 :(

      I'm not quite sure how to work around this problem, save only deploying a single ear, which seems non-ideal, or some other equally smelly workaround.

      Any ideas?

        • 1. Re: 3.2.0 Classloader issue

          can you deploy the X.jar just once by extracting it from the ears as its own unit (*.jar will get deployed from the deploy dir), and remove it from the ears.

          • 2. Re: 3.2.0 Classloader issue
            pants

            OK, so I tried pulling out all the shared jars from the two ears, and just dropping them in the deploy directory and it sort of worked.

            Problem is, I had to leave struts.jar, jstl.jar and the tlds in the WEB-INF/lib directory of a war in the A.ear.

            It seems OK now, but presumably I will get the same "duplicate class found" if I deploy another ear with a war that needs struts or jstl.

            Plus this kind of circumvents the whole idea of packaging required libraries inside ears.

            Does this behaviour represent the new classloading semantics or is it a bug?

            • 3. Re: 3.2.0 Classloader issue

              I'm not sure why you're getting the LinkageError in the first case, was X.jar in WEB-INF/lib too?

              In the second case I think it should be an option to fallback to serialization for calls between ears (even though it has a performance impact) and let the Java serialization worry about incompatibility between class definitions. Might be worth a RFE to see if there's any feedback to that.

              If X.jar was under WEB-INF, can you try to share it at the EAR level (by adding module in your application.xml)?

              • 4. Re: 3.2.0 Classloader issue
                h.buerger

                There is a document describing the new class loader, ClassLoading.pdf on sourceforge.net (All files/Documentation).
                I didn't fully read it yet but it it seems to answer your questions about class loading.

                Regards
                Haug

                • 5. Re: 3.2.0 Classloader issue
                  pants

                  After having read around and played around with various methods of packaging... the recommended way to package J2EE applications seems to deploy everything in a single ear.

                  i.e. "An EAR is a deployment contract. Each EAR should represent a complete application and should not rely on code external to the EAR file, except what is provided by the application server itself."