New Article on J2EE Class Loading Architectures Posted on TSS

Discussions

News: New Article on J2EE Class Loading Architectures Posted on TSS

  1. This article helps J2EE developers better understand the class loading architectures of a variety of application servers and how the components of a particular J2EE application are loaded. Armed with this information, J2EE developers can design portable J2EE packaging structures or at least understand the tradeoffs when using proprietary techniques.

    Read "Understanding J2EE Application Server Class Loading Architectures"

    Threaded Messages (34)

  2. Any suggestions how a _portable_ J2EE-application should be constructed in practise (by using war and ear files), assuming that we have 2 different servers: one for EJBs and and another for jsp:s, servlets and plain java classes? Both should have access to some shared classes too.
  3. I find these two articles on Sun's website very useful and should answer your questions.

    -Srini
  4. oops.. the links.

    http://developer.java.sun.com/developer/technicalArticles/J2EE/build/

    http://developer.java.sun.com/developer/technicalArticles/J2EE/build/build2.html


  5. Another (older but useful) article



  6. Que tonto.
    Seems I skimmed a little too quickly over the references - the article is already referenced...

  7. This is a good question and the links provided by Srini are indeed useful. It's been my experience that utilizing a truly portable J2EE packaging format (i.e., no proprietary extensions and no violations when run/validated under the J2EE reference implementation) often results in duplicated code and unintuitive packaging layouts. This is not always the case, but in the context of "older" code that may not have been designed specifically for J2EE deployment, it is common.

    Let me provide some context for this response. I wrote this article as a result of a decision to officially support a large number of J2EE application servers for our stateless session EJBs and struts-based web application framework (portions of a product called SpatialFX). The product is a set of extensible J2EE components that provide a development platform for Location Based Services applications. The problem of shipping extensible J2EE components and documenting the interaction between all the necessary pieces is not trivial when the user environment is completely unknown.

    After chasing the Holy Grail of portable packaging, I finally decided that it would be much better for our users (most of whom use one app server for all containers, or maybe mix Tomcat into the equation) to automate the suggested packaging structure depending on which components they wanted to use and which app server they wanted to target. The resulting J2EE Application Packaging Kit is an Ant 1.4.1-based tool that is invoked with a customized script that takes two parameters: (1) the target app server, and (2) the J2EE component(s) desired. Here is an example invocation:

    buildJ2EE.sh weblogic6.1 ear_ejbjar

    This would result in an .ear file made up of one .jar file containing all of our fully configured stateless EJBs (there is a properties file to set some of the configuration information that ends up inside the .xml config files). The intent is that the user can use this .ear as is or take it apart and add more code as he/she sees fit. It is optimized for the app server listed and is typically much more compact and clean. Other supported J2EE component parameters include "war", "ear_war", "ejbjar", and "ear_war_and_ejbjar".

    Notice that a portable J2EE 1.3.1 reference implementation target could be viewed as just one more app server.

    The downside to this approach is maintenance. We decided to accept that since the benefits were many for our type of product.

    This doesn't directly answer the question, but I hope it shows how automation (especially with an excellent tool like Ant) can make portable packaging formats less important in some cases.

    Brett
  8. I move this shared classes into system classpath.
  9. Thanks for the great article Brett! It’s really interesting to see the differences and similarities between vendors. I’ll add JRun 4 to the mix here.

    The basic module loading in JRun 4 looks similar to the WebLogic picture with two differences- there is an extra, super-EJB class loader right below the system class loader, and there are individual class loaders below the web app class loader for each JSP.

    The super-EJB class loader allows us to get around remote-EJB-in-same-VM performance issues, while the single class loader for each JSP provides better class isolation than renaming the JSP class on each reload.

    JRun 4 also supports ClassPath manifest entries in all modules.

    An interesting class loader-related feature of JRun is built-in instrumentation support. Instrumentation of any classes being loaded can be done through the jrunx.instrument.InstrumentationService, which allows sub-services that implement Instrumentor to modify the raw bytes of a loaded (but not yet resolved) class. We have one implementation of Instrumentor that inserts statements for method timing, but there’s lots of other cool things that could be done here.

    A more esoteric class loader in JRun is our dynamic class loader. This class loader is used when the reload or compile options are enabled in jrun-web.xml. The dynamic class loader is an interesting piece of work that will reload a class when a dependent class changes and compile a class for a java file when needed and possible. It’s really good at only reloading the classes needed rather than dumping everything.

    One final note for current/future JRun-users- if you ever run into class loader troubles with JRun, try this debug line:
    System.out.println(jrunx.util.JRunURLClassLoader.classloaders());
    It’s similar to Brett’s code for printing out the current class loader hierarchy, and it will also print out the jars related to each JRun class loader.
  10. Brian: Thanks for the JRun information; it will come in handy down the road. I particularly like the support for easily dumping the class loading hierarchy. I need to take a look at JRun again soon; it sounds like you've been doing some truly cool stuff lately.

    I would also very much like to hear about the classloading details of other app servers should anyone have that information available. Oracle 9iAS Release 2 (and how it may differ from Orion) and JBoss are particularly interesting to me.

    Brett
  11. would also very much like to hear about the classloading details of other app servers


    Orion uses much like the same hierarchy as Weblogic.

    Basically something like this (in my small test app):

    This is the war class loader:

    com.evermind._ksb@7a1576
    [ClassLoader: [[C:\orion\applications\thyesteanfeast-j2ee\thyesteanfeast-j2ee-web\WEB-INF\classes], [C:\orion\applications\thyesteanfeast-j2ee\thyesteanfeast-j2ee-web\WEB-INF\lib/sitemesh.jar], [C:\orion\applications\thyesteanfeast-j2ee\thyesteanfeast-j2ee-web\WEB-INF\lib/thyesteanfeast-j2ee-web.jar], [C:\orion\applications\thyesteanfeast-j2ee\thyesteanfeast-j2ee-web\WEB-INF\lib/velocity.jar], [C:\orion\applications\thyesteanfeast-j2ee\thyesteanfeast-j2ee-web\WEB-INF\lib/webwork.jar]]]

    This is the ejb class loader:

    [ClassLoader: [[C:\orion\applications\thyesteanfeast-j2ee/thyesteanfeast-j2ee-ejb.jar], [C:\orion\applications\thyesteanfeast-j2ee/log4j.jar]]]

    This is the orion.jar class loader:

    [ClassLoader: [[C:\orion\lib], [C:\orion\lib/bsf.jar], [C:\orion\lib/commons-collections.jar], [C:\orion\lib/hsql.jar], [C:\orion\lib/js.jar], [C:\orion\lib/log4j-core.jar], [C:\orion\lib/pgjdbc2.jar], [C:\orion\lib/saxon.jar]]]

    Other 2 class loaders at top of hierarchy:

    sun.misc.Launcher$AppClassLoader@71732b

    sun.misc.Launcher$ExtClassLoader@7fdcde

    --

    Log4j is loaded from ejb Manifest.mf file.

    It pretty sure that Oracle uses the same class loader hierarchy.
  12. There's also a JSR out regarding packaging and deployment - this may be worth considering. I think it is JSR 76.
  13. I think you mean JSR88 found here:

    http://www.jcp.org/jsr/detail/88.jsp
  14. I think you mean JSR88 found here:

    > http://www.jcp.org/jsr/detail/88.jsp

    Thanks for the pointer. The summary document seems to imply that this JSR will provide standard deployment tool APIs for deploying assembled J2EE applications on J2EE-compliant platforms. I take this to mean that I could build a deployment tool that could work against WebLogic, WebSphere, Oracle, etc...

    However, it seems that the requirement for adherence to J2EE packaging layout rules would still exist. In other words, if I package an .ear with a .war that relies on a Manifest Class-Path entry (a non-standard option), the common deployment tool may not correctly deploy that app on an app server that didn't support .war Manifest Class-Path entries. If anyone knows if this is a false statement and I am misreading the JSR, let me know.

    Brett
  15. Brett,
    a first draft of the ClassLoader architecture of upcoming JBoss 3 can be found at:
    http://www.jboss.org/forums/thread.jsp?forum=67&thread=15974

    Ciao,
    Tobias
  16. Thanks for the JBoss 3 link, Tobias...

    Brett
  17. Thought i'd share some of my experiences packaging j2ee for weblogic. The environment we were working with involved an open deployment (exploded war, and a collection of ejb jars) in development, then a packaged .ear for deployment to production.

    The classloader architecture is different when running a non-ear deployment, as described in your article. Each ejb jar and the war have seperate, sibling classloaders. This means that the war does not inherit from the ejb classloader, and therefore needs its own copy of common classes. At this point calls from the war to ejb methods are made over rmi. So if an object is instantiated in an ejb against class x then passed to the web app, it is first serialised and then deserialised in the web app against the web app version of class x, obviously fine.

    However, if the same products (packaged war and ejb jars) are now deployed as an .ear, a problem occurs. Weblogic assumes (quite fairly) that because you are deploying as an ear, that it can localise method calls from the war to the ejbs since they will be running within the same jvm. Now remember that the war has copies of common classes, but the classloader now inherits from the ejb classloader. Now when an object is instantiated against class x in an ejb then passed directly to the web app (whoose classloader has also loaded class x), a classcast exception occurs since a class is identified by name and the classloader that loaded it.

    The solution to this problem is to make sure that there are no duplicate classes loaded by the war classloader that are also loaded by the ejb classloader. This can be done my manually determining the dependencies between war and ejb, or simply making sure that there is just one version of a class loaded for the entire application.

    Our implementation took this to an extreme. All classes (ejb app and web app) where packaged into a common.jar file. Generic ejb jar files were then produced for each ejb, containing only the descriptors, with reference to common.jar from the manifest. EJBC is then invoked on these ejb jars and the stubs and skeletons are compiled and inserted.

    The war contains nothing other than the web deployment descriptors and the jsp (or precompiled jsp). It can see classes in common.jar since its classloader inherits from the ejb classloader.

    The result of this packaging structure is the ear file has no duplicate classes, and is safe to deploy in a weblogic that attempts to localise method calls to ejbs. Note it is also safe to deploy in a cluster, since calls will still work over rmi as well.

    The build process was scripted with ant 1.4.


    Hope this was of interest,

    Joe
  18. Quote: "Now when an object is instantiated against class x in an ejb then passed directly to the web app (whoose classloader has also loaded class x), a classcast exception occurs since a class is identified by name and the classloader that loaded it. "


    I don't understand it. The ejb classloader is parent of the war classloader. If the ejb classloader can load x, that class should not be loaded by the war classloader. The war classloader will ask the parent (ejb classloader) to load the class. Only if the ejb classloader cannot load the class x, the war classloader will load it. Incidentally, which version of the application server are you using?

    -Mahesh
  19. Mahesh wrote regarding Joe's post:
    > I don't understand it. The ejb classloader
    > is parent of the war classloader. If the
    > ejb classloader can load x, that class
    > should not be loaded by the war classloader.
    > The war classloader will ask the parent
    > (ejb classloader) to load the class. Only
    > if the ejb classloader cannot load the class
    > x, the war classloader will load it.
    > Incidentally, which version of the
    > application server are you using?

    Mahesh makes a good point about Joe's scenario, and with WebLogic 6.1 SP2 I don't think the error as described would occcur.

    A scenario in which Joe's issue could occur with WebLogic 6.1 before SP2 is if class x is in common.jar and common.jar is referenced from the Manifest Class-Path of both the .war and .jar. WebLogic 6.1 SP2 (under WebLogic issue 056911) altered the class loading semantics in this scenario (a big improvement in my opinion).

    I'm guessing this is why Mahesh asked which version of WebLogic Joe is using. It potentially makes a difference in this case depending on how Manifest Class-Path settings are being used.

    Brett
  20. We have also worked to optimize our packing of EJBs to be as portable as possible. At one point we chose the packaging described by Joe Stableton.

    However, in a real-life scenario it seems intuitive to add new glue classes and code from other vendors to the web application (WEB-INF/lib or WEB-INF/classes). This does not pose a problem in itself, except in the following scenario:

    Lets say that you have some JSP tag that takes a class name as attribute and then loads the class. In Joe's scenario, the tag class will be in common.jar and will be loaded by the EJB classloader. But if a customer writes a new class to be used with this tag and puts this class in WEB-INF/classes (which would be an obvious place), then the class cannot be loaded by the tag class because the EJB classloader cannot see the web classloader.

    Even worse, lets say that you have such a scenario as part of your "foundation" classes that should be common to all your code, then even if you keep all web related code on the web tier, but if the specific class that loads another class happens to be in your foundation library and thus is loaded by the EJB classloader, then it wouldn't work if the class being loaded is only available to the web classloader.

    Personally, I find this annoying because I like "pluggable" patterns where you use Factories to load specific implementations to some interface to make some functionality configurable and late-bound.

    Obviously, the class that loads other classes must be loaded by the same classloader. This requires it to be available to every classloader that uses it, which I think is all right (the logistical problem of deployment one class in many places is manageable).

    But even if you deploy this one class under all classloaders, it will still not work. Because a classloader will always ask its parent classloader *before* it attempts to load the class itself. The class would *always* be loaded in the wrong place.
  21. Quote:
    "But if a customer writes a new class to be used with this tag and puts this class in WEB-INF/classes "

    The deployment strategy i described is only for the production ear deployment. Using a simple ant build script there is no ability for the customer to influence where the class is placed, unless they alter the script. The customer simply writes his classes, and runs the ant script which compiles them all and jars them into common.jar. Whether or not the customer placed his class in WEB-INF/classes during development, is irrelevant.

    I agree though that if the new class was placed in WEB-INF/classes in the ear, then it would fail.

    Joe
  22. I completely understand your approach and I agree it's a good one.

    But my point remains valid. The way hierarichal classloaders work does pose problems with commonly deployed code that make use of classloading for pluggability reasons.

    Cheers,
    Jesper

  23. Jesper wrote:
    > But even if you deploy this one class under
    > all classloaders, it will still not work.
    > Because a classloader will always ask its
    > parent classloader *before* it attempts to
    > load the class itself. The class would
    > *always* be loaded in the wrong place.

    It's an interesting exercise to juxtapose the statement above with the classloading semantics of WebSphere 4.0. While standard class loaders typically ask their parent for a class first, WebSphere actually parameterizes this behavior.

    Follow the links to section 6.4.1 of the WebSphere documentation in the article. In there you'll see a description of the "Delegation Mode" parameter for war and ejb jar components. WebSphere allows the definition of the following two system properties:

    com.ibm.ws.classloader.warDelegationMode (false by default)

    com.ibm.ws.classloader.ejbDelegationMode (true by default)

    The values of these properties control the classloading semantics of wars and ejb jars independently. A value of false implies that the war or ejb jar first searches its "local" codebase before asking its parent for a class. A value of true implies that the war or ejb jar asks its parent first before searching its "local" codebase.

    Note that a value of true corresponds to the typical class loader behavior (parent first). However, the default setting for war modules is false and the default setting for ejb jar modules is true. For the product I work on (ObjectFX's SpatialFX), we needed to make some assumptions about how these properties would be set when suggesting a packaging layout for a customer.

    When working with WebSphere 4.0 (or any app server), details like this are useful to know.

    Brett
  24. Thanks for the useful info on WebSphere.

    I was guessing that other app servers might have a mechanism like this and/or that BEA is considering it for future releases.

    But the app server specific solutions to this problem make it difficult for a J2EE programmer to assure that his code works the same way on different app servers. I wouldn't call it a straight-forward problem that is easily identified and resolved.
  25. We were using wl6.0 sp2, rolling patch 1. The rolling patch was required to use the manifest class-path extension mechanism.

    If the war classloader now (6.1sp2) checks with the parent ejb before loading, guaranteeing only one version of a class is loaded in a single jvm, then this problem will not occur.
  26. We were using wl6.0 sp2, rolling patch 1. The rolling patch was required to use the manifest class-path extension mechanism.

    If the war classloader now (6.1sp2) checks with the parent ejb before loading, guaranteeing only one version of a class is loaded in a single jvm, then this problem will not occur.

    Joe
  27. Joe wrote:
    > Thought i'd share some of my experiences
    > packaging j2ee for weblogic.

    From my perspective, Joe's post exemplifies why understanding the class loading architecture of a chosen app server needs to be a high priority in any J2EE project. The errors that are attributable to class loading issues are not difficult to quickly fix when there is an understanding on the team of how things are structured internally. Conversely, a lack of understanding can make class loading errors seem insurmountable. Joe's demonstrated knowledge of WebLogic's approach obviously makes his job a lot easier.

    Theoretically it shouldn't have to be that way, but practically it is. Note that I included links to online app server documentation in the References section to make the point that this information is often (but not always) documented fairly well.

    Brett
  28. <quote>
    Weblogic assumes (quite fairly) that because you are deploying as an ear, that it can localise method calls from the war to the ejbs since they will be running within the same jvm.
    </quote>
    Quite an interesting discussion so far. However I have a question, which may really not be appropriate in this thread. But I'll still go ahead and ask it. Can anyone explain how WebLogic is able to localize method calls to the ejb's as claimed above? Based on my understanding of RMI, I believe that whether you have a local method call or a remote call really depends on whether you have a stub or the actual object reference. Which really boils down to whether the very first reference that you obtain is an actual object reference or a remote ref.
    Does this mean that the context.lookup() call returns the actual ejbHome reference instead of the stub if the ejb's are local? How does WebLogic know when to replace stubs with actual object references?

    Please pardon my less than perfect understanding of ejb's :-)
     
  29. Quote from bea docs
    "The EJB classloader is a child of the Java system classloader and the Web application classloader is a child of the EJB classloader. This allows classes in a Web application to locate EJB classes, but EJB classes cannot locate Web application classes. A positive side-effect of this classloader hierarchy is that it allows servlets and JSPs direct access to EJB implementation classes. WebLogic Server can bypass the intermediate RMI classes because the EJB client and implementation are in the same JVM. "

    Doesn't really explain how they decide to localise the call, more how it is possible. This was a black box i didn't have time to unwrap on the project.

    Joe
  30. This article describes the classloading in Orion (and OC4J):

    http://kb.atlassian.com/content/atlassian/howto/classloaders.jsp

    Cheers,
    Scott
  31. An interesting problem occurs when you want to pass a Proxy (java.lang.reflect.Proxy)
    class to an EJB. Since the proxy always uses the system classloader, the interfaces implemented by the Proxy instance will not be found by the app server child class loaders when RMI tries to unmarshal the Proxy. THis would seem to be a major problem with Proxy ... please feedback if anyone has a fix.
  32. I have a question regarding WebLogic Class loading. We managed to comp up with a ear for weblogic and wintin the WEB-INF/classes directory we had inclded the some servlet classes like HttpServlet class.

    This caused problem when we deplyed our application on WebLogic. As I understand the class loading architecture of WebLogic the before the WEb-INF/classes are loaded servlet classes would be loaded. Therefore even if we had bundled the servlet classes it shouldn't create a problem since the parent class loader would have already loaded these classes.

    Please clarify this issues if there is anything we are doing wrong in deployment?

    Senthoor
  33. If I understand you correctly you placed some classes from the weblogic web app container (eg, HttpServlet) within the web app itself.

    Depending on the version of weblogic (apparently this is fixed in 6.1sp2) a classloader will not check whether its parent has already loaded a class before it loads the class itself.

    What is happening with your deployment is your servlets are being instantiated against the HttpServlet definition loaded by the war classloader, while the web app container is expecting servlets to subclass HttpServlet in the system classloader. Therefore you will get classcast exceptions at best, but probably just cause the web app container to die.

    Joe
  34. OC4J / NoClassDefFound error[ Go to top ]

    I'm trying to deploy a JSP application on OC4J, but I'm getting a confusing error message (see below). Actually, parts of the app are available; this message appears only when trying to access a particular page (which happens to be the 'front' page, the most important page). I've tried to deploy the app on two similarly configured machines (test and production). This problem does not occur on the test box; only on the production box. We are starting OC4J using the command 'java -jar orion.jar'. The class that it says is not defined is right there in orion.jar! Any clues? Why would it work on one box but not the other? As far as I can tell, there are no significant differences! Here's the full error message:

    java.lang.NoClassDefFoundError: javax/servlet/jsp/tagext/TagSupport at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106) at java.net.URLClassLoader.defineClass(URLClassLoader.java:243) at java.net.URLClassLoader.access$100(URLClassLoader.java:51) at java.net.URLClassLoader$1.run(URLClassLoader.java:190) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:183) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106) at java.net.URLClassLoader.defineClass(URLClassLoader.java:243) at java.net.URLClassLoader.access$100(URLClassLoader.java:51) at java.net.URLClassLoader$1.run(URLClassLoader.java:190) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:183) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106) at java.net.URLClassLoader.defineClass(URLClassLoader.java:243) at java.net.URLClassLoader.access$100(URLClassLoader.java:51) at java.net.URLClassLoader$1.run(URLClassLoader.java:190) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:183) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:287) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281) at java.lang.ClassLoader.loadClass(ClassLoader.java:287) at java.lang.ClassLoader.loadClass(ClassLoader.java:287) at java.lang.ClassLoader.loadClass(ClassLoader.java:287) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at com.sas.psg.portal.ioContentZone.getIoTagOutput(ioContentZone.java:1133) at com.sas.psg.portal.ioContentZone.getContentZoneOutput(ioContentZone.java:840) at /beanWidgetMenu.jsp._jspService(/beanWidgetMenu.jsp.java:96) (JSP page line 52) at com.orionserver[Oracle9iAS (1.0.2.2.1) Containers for J2EE].http.OrionHttpJspPage.service(OrionHttpJspPage.java:54) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.HttpApplication.serviceJSP(HttpApplication.java:5459) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.JSPServlet.service(JSPServlet.java:31) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:508) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.include(ServletRequestDispatcher.java:94) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.EvermindPageContext.include(EvermindPageContext.java:284) at /frontPage.jsp._jspService(/frontPage.jsp.java:111) (JSP page line 77) at com.orionserver[Oracle9iAS (1.0.2.2.1) Containers for J2EE].http.OrionHttpJspPage.service(OrionHttpJspPage.java:54) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.HttpApplication.serviceJSP(HttpApplication.java:5459) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.JSPServlet.service(JSPServlet.java:31) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:508) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:177) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:576) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:189) at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].util.ThreadPoolThread.run(ThreadPoolThread.java:62)
  35. Outdated stuff?[ Go to top ]

    Not really a new article. The versions of the app servers are outdated. The classloading of Websphere 5 has been seriously updated from Websphere 4.
    Ex: configurable parent first, parent last classloading policies