7 Replies Latest reply on Oct 15, 2002 10:49 PM by Adrian Brock

    Mutliple ears with similar files

    integ Newbie

      I am trying to deploy 2 ears with the same files. These ears contain some utility class files in addition to the bean classes. These utility classes are slightly different across the 2 ears. My observation is that the utility class files belonging the ear which gets deployed first are the ones which take effect. Similarly named files from the second ear are probably ignored. So what happens is the 2nd ear makes use of the utility classes from 1st ear. How can i make each ear use its own utility class files.

        • 2. Re: Mutliple ears with similar files
          integ Newbie

          Adrian, I tried that, but doesnt work for me.

          This is the jboss-app.xml file that goes into the META-INF section of ear 1.

          <jboss-app>
          <loader-repository>localhost:8080:loader=xyz1.ear</loader-repository>
          </jboss-app>


          This is the jboss-app.xml file that goes into the META-INF section of ear 2.

          <jboss-app>
          <loader-repository>localhost:8080:loader=xyz2.ear</loader-repository>
          </jboss-app>


          But xyz2.ear continues to load utility files from xyz1.ear.

          Plz tell me where i am wrong.

          • 3. Re: Mutliple ears with similar files
            Adrian Brock Master

            You don't have a valid jmx ObjectName

            try something like

            <loader-repository>repository:loader=xyz1.ear</loader-repository>

            There was some talk about reversing this behaviour,
            making ears a classloader scope by default with a flag
            to not isolate it. I don't think it has been done yet.

            Regards,
            Adrian

            • 4. Re: Mutliple ears with similar files
              integ Newbie

              Adrian,

              that too didnt work for me. I think i missed telling u an important point. I am on JBoss3.0.0 and not JBoss3.0.1. Do u think this might work on JBoss3.0.1, or is there anything else that i can do abt this.

              • 5. Re: Mutliple ears with similar files
                David Jencks Master

                Most likely you will need a cvs version of Branch_3_0, Branch_3_2, or head. There was a bug when mbeans were involved, just fixed today by Scott in I think all 3 versions.

                • 6. Re: Mutliple ears with similar files
                  narve2 Newbie

                  > Most likely you will need a cvs version of
                  > Branch_3_0, Branch_3_2, or head. There was a bug
                  > when mbeans were involved, just fixed today by Scott
                  > in I think all 3 versions.

                  Does this mean that "loader-repository" does not work at all? That there are no ways to have two different versions of a library? And are there any dates for a 3.0.4 (or 3.2.0)?

                  Some further "loader-repository" questions:

                  I've had the same problem as several other users in the forums, and tried specifying loader-repository. Unfortunately, the classes were still loaded from the wrong ear (the first to be deployed). I have not tried using a loader-repository in all ear's, as there are many of them.

                  What exactly happens when you specify a loader? After reading the (slightly vague) comments, things are a bit unclear. My understanding was that specifying a loader gives you a special loader that first looks in its own local repository (usually, in the ear/war file) and thereafter in the general repository. However this is not the behaviour I observed. Is the other way, that by specifying a repository the classes are excluded from other class loaders, but Class.forName will still look in other repositories first?

                  Furthermore, the symptoms in my case were actually a ClassNotFound-exception: In one library (in app1.ear) I have a library class C that uses Class.forName(...) to load another class. This works fine. I then deploy app2.ear, containing another version of library C, and calls Class.forName on a class that is found in app2.ear. This causes a ClassNotFound-exception. Should it? Can anybody explain this? There seem to be no information about this in the documentation, except the small paragraph that was posted in the forum.

                  (Just in case: jboss-3.0.3, jdk1.4, win2k)

                  • 7. Re: Mutliple ears with similar files
                    Adrian Brock Master

                    A loader repository is a separate classloader space.

                    In default jboss, there is only one loader repository,
                    all classes can see each other (or very nearly see later).
                    This allows optimal processing between the different
                    components installed.

                    By specifying <loader-repository> in jboss-app.xml
                    you create a new classloader space, allowing you to
                    vary class definitions for different apps. It can see
                    the classes in the main loader repository and its own
                    classes.

                    It cannot see classes in other ears with a
                    <loader-repository> unless....

                    If you specify the same name in <loader-repository> for
                    two ears, they share the same classloader space.

                    Use a naming convention like
                    <loader-repository>loader-repository:ear={your-ear-package-name-here}</loader-repository>
                    to avoid sharing.

                    There are other complications, like the bootstrap
                    classloader and wars get their own classloader
                    that branches from the relevent <loader-repository>.
                    wars can see ejb classes but not the other way around.

                    Don't use Class.forName() use
                    Thread.currentThread().getContextClassLoader().loadClass()
                    But that would take another long explanation.

                    The bug Scott fixed was for MBeans inside an
                    ear with a loader-repository.

                    Regards,
                    Adrian