3 Replies Latest reply on Feb 13, 2002 11:19 AM by Adrian Brock

    Ruling on JAR locations ?

    Frank Griffin Novice

      There are hundreds of comments in here about lib/ext and how this or that JAR file should be in this or that place. IBM recently had a WebSphere article that concisely described how WebSphere uses classloaders, and exactly who would see JARs you placed at any of their three levels (CLASSPATH, ws.dirs, EAR/WAR WEB-INF/lib).

      Could we please get a complete and definitive ruling on the same situation for JBoss ? I *think*, from reading stuff here, that there is $JBOSS_CLASSPATH, $JBOSS_DIST/lib, $JBOSS_DIST/lib/ext, $JBOSS_DIST/deploy, and WEB-INF/lib. My impression is that nobody ought to be using the first two, but I'd like to hear the philosophical distinctions between the rest.

      What code supplied by users of JBoss should expect to be able to see classes in JARs in lib/ext and deploy ? Outside of hot deployment, is there any difference between the two ? Is it a waste to add the same utility classes to every app that needs them, or do servers check things like timestamps and map references to instances of classes which are identical in different applications to the same physical bytecode in memory ? In other words, is it just a waste of disk or of runtime resources ?

      Thanks,
      Frank

        • 1. Re: Ruling on JAR locations ?
          Adrian Brock Master

          Which version?

          The 2.4 and 3.0 classloaders are different.
          The 3.0 version should be a lot easier to use.

          Some general points applicable to both.

          1) Don't put anything in JBOSS_CLASSPATH, it will only be
          able to see other jars in JBOSS_CLASSPATH during class
          loading.

          2) jboss/lib jars are added using MANIFEST.MF in run.jar
          so adding anything there won't work

          3) jboss/lib/ext is for utility jars you wouldn't expect
          to change, everything except the first two can see these
          classes (see jsps below)

          4) jboss/deploy/YourApp.ear this is the preferred place
          for helper jars that need hot deployment (see jsps below)

          5) WEB-INF/lib I think this is only useful for wars that
          need helper classes (see jsps below)

          JSP note
          There seems to be some problem with the classpath for
          jsp compilation. It doesn't use the classloader.
          Instead, it uses WEB-INF/classes and WEB-INF/lib
          plus the web-container's classes.
          I've seen it mentioned that it also uses the
          META-INF/MANIFEST.MF classpath element on some Web
          containers/versions.
          This can cause problems for jars in the ear and
          makes it impossible to reference lib/ext classes.
          WARNING: I don't use JSP. This is all stuff I've
          picked up from other posts.

          On your final point. If a class is loaded from a
          different classloader it is a different class, regardless
          of timestamp or bytecode.

          Regards,
          Adrian

          • 2. Re: Ruling on JAR locations ?
            Frank Griffin Novice

            Thanks for the reply.

            My interest was for 3.0.0.

            When you say "JSP compilation", is it limited to that or might this problem be bleeding over into the runtime classpath for any WAR application ?

            The case I tried was installing Axis by creating an axis.war from their webapps/axis directory (which contains an index.html and WEB-INF with lib containing several JARs). This worked fine. I then removed the JARs from WEB-INF/lib, recreated the axis.war without them, added all of the JARs to $JBOSS_DIST/lib/ext, and restarted JBoss. After that, attempts to use the WAR failed because classes in the JARs couldn't be seen.

            This was the jboss-3.0.0alpha download version. I'll try it with DR1 as soon as I can get a CVS version to work.

            I guess the classloader question boils down to whether JBoss is using different classloaders for different EARs and WARs. It seems like it would have to in order to keep different versions of identically-named classes separate (e.g. people packaging their own log4j.jar), but the WebSphere article mentioned (I think) some capability to tell the server to use a separate classloader for each app, or a single classloader for all of them.

            I'm pretty new at this, but it seems like there is an incredible potential for having (N where N is large) versions of the identical class loaded in memory.

            • 3. Re: Ruling on JAR locations ?
              Adrian Brock Master

              I don't know how Axis deals with the classloader,
              but I know there's been a fair bit of work done on it
              since 3.0.0alpha.

              For DR1, I think this will work.
              Each application/jar gets it's own classloader.
              This classloader is also added to a global pool.

              If the class cannot be found in its own classloader,
              it uses the global pool to load the class.

              I've not delved too deeply into the code yet, so
              don't ask me any complicated questions :-)

              CVS is getting close. It should be branching for the DR1
              release on Friday???

              Regards,
              Adrian