Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
JTurbo Self-Help: FAQ
Back to Search >  Back to Search Results

Faq ID 244
Product ServletExec
Category Class Loading/Reloading
Question How does ServletExec use various classloaders to find and load class files, and how can this effect my Java Servlet web applications ?
Answer ClassLoaders in Java operate on a parent-child scheme, which is analogous to Object Oriented concepts as follows:
Children "inherit" from their parents, but parents cannot use the functionality of their childen.
At the top is the JVM's own default, basic System Classloader, which looks in various places for classes.
Places such as:
  • The JVM's main classpath as defined by the -classpath option
  • The JVM's boot classpath, JARs in it's extensions folder, or JARs in its endorsed folder. These are specified by the following JVM system properties (respectively):
    • sun.boot.class.path (C:\j2sdk1.4.2_04\jre\lib\rt.jar;C:\j2sdk1.4.2_04\jre\lib\i18n.jar;... for example)
    • java.ext.dirs (C:\j2sdk1.4.2_04\jre\lib\ext for example)
    • java.endorsed.dirs (C:\j2sdk1.4.2_04\jre\lib\endorsed for example)

Code that's loaded into the JVM by the System classloader can be written to create it's own custom classloader(s), which can be written to look for class files in other places.
This is what SE does to support Java Servlet Web Applications and JSPs running inside those web applications.
Here is a graphic representation of Classloaders in SE:
System Classloader (provided by the JVM)
         |
         |
         |
        / \
       /   \
      /     \
    app     app classloader
classloader  | 
     |       | 
     |       |
     |       |
   JSP       JSP classloader
 classloader

Each webapp gets its own custom application classloader which will be used to find classes in the following order:
  1. .class files in WEB-INF/classes
  2. .jar files in WEB-INF/lib
  3. Any classes that reside in any external libraries that have been setup for the webapp
If the custom application classloader still can't find the class, it will ask its parent classloader (i.e. the Java System Classloader) to find the class.

Each webapp also gets its own custom JSP classloader which will be used to find classes in that webapp's pagecompile folder.

A child classloader can ask it's parent to find (and thus load) a class, but the reverse is not true.

If you have a class 'b' that is visible to a higher-level classloader, and that class implements or extends some other class 'a', then class 'a' must also be visible to that higher-level classloader. Otherwise the JVM won't be able to load class 'b', because when it tries to do so, it will see that 'b' extends or implements 'a' and won't be able to find 'a'. You'd likely get a NoClassDefFoundError which mentions class 'a'.
Class 'a' would need to be visible to the same classloader as is class 'b' (or visible to a higher-level classloader).


Example: placing a Servlet class file (which neccessarily extends javax.servlet.http.HttpServlet) into the JVM's extension folder, but not placing servlet.jar (which contains javax.servlet.http.HttpServlet.class) there as well.



   
company media information terms of use privacy policy contact us