2 Replies Latest reply on Dec 29, 2002 10:00 AM by Michael Ingardia

    ClassLoader 3.0 vs 2.0

    Michael Ingardia Newbie

      We have an application that works fine in 2.44. We are attempting to port to 3.01.

      Some background:
      We have broken our application in to the following parts:

      1. Client Side UI Classes (mainly uivalue objects passed to JSP's and Struts Action Classes etc)

      2. Common Classes (utility classes used by both client and server packages, data value objects (structs to carry data, and collection classes), and interfaces (business delegate interfaces), exception classes.

      3. Server Side Classes business delegate implimentation classes, EJB Home, Remote Interface Classes, EJB impl and other server specific classes.

      From this layout as you would expect the client and server are not depenent on each other, although both sides are dependent on the common classes. The common classes are non-ejb specific and are all contained in one jar file app-common.jar. Many EJB Jar files need classes from the app-common.jar. In 2.44 we added the app-common.jar to both the WAR, and the EAR file, although this created some minor issues it worked well.

      In 3.0 the class loader architecture has changed. A "unified" class loader model is talked about in the documentation. Unfortunately the documentation is unclear how the "correct" application is to be packaged. Should we place copies of the common class files in each ejb jar file? Is there some descripter property (perhaps the ejb-ref element) that should be used to reference the app-common.jar? How would this be done in 3.0. For now our application throws a class not found exception looking for a class in the app-common.jar. We have tried placing the app-common.jar in the deploy directory and that did not help.

      Any one got some answers?


        • 1. Re: ClassLoader 3.0 vs 2.0
          Michael Ingardia Newbie

          An Update,
          Was able to get past the first exception of not finding the EJB class in JNDI context by adding a ejb-ref and a jboss-web.xml file. Still however can not load the interface class. In our business deligate we do a class.forName, and I suspect that perhaps we need to use the thread context to load the delegate implimentation. Not sure but will try this next. End result however is we are still getting a class not found exception, when looking for the interface class. Any one know the "right" way to dynamically load a class, such that it is loaded by the right classloader and has visibility into deployed ejb jar files?


          • 2. Re: ClassLoader 3.0 vs 2.0
            Michael Ingardia Newbie

            Having our business delegate loaded via the thread context loader worked... Although from time to time we still get the class not found error on the first load of an EAR. Restarting the server clears it up, and from that point on we seem to be fine which is very strange. Perhaps its some packaging problem. In the end we are now on our way to 3.x compatability