Java and tomcat class loader, priority & hierarchy

Java class loader hierarchy

We have 3 main class loader :

  • Bootstrap class loader, called primordial class loader. It’s a part of the JVM., and is responsible for loading classes from the core Java package (java.lang, java.util etc.) These classes are found in JAVA_HOME/jre/lib/rt.jar.
  • Extension class loader. It monitors the JAVA_HOME/jre/lib/ext folder and load the existing jars.
  • System class loader. It monitors the folders and Jars which can be find in the classpath.

An important point is that a class loader can only see the class locations that are above it in the hierarchy. So a class loaded from Extension class loader can’t see a class from the class path.

Tomcat / java EE hierarchy

For security reason, each web app must use its very own class loader (you don’t want to share any class with another malicious application)
During startup, tomcat neutralize the System class loder by clearing the classpath.
It also changes the endorsed directory to point to CATALINA_HOME/endorsed.
Doing so, the class-loader hierarchy is reversed:

  • Tomcat internal class loader. Loads classes for tomcat internal code. Web applications can’t use this class loader.
  • Web application class loader. Loads classes from the WEB-INF/classes (first) and WEB-INF/lib for a webapp
  • Shared class loader. Loads classes from the folder specified in catalina.properties. Theses classes are visible only to all web apps.
  • Common class loader. Loads classes from CATALINA_HOME/lib (all web apps + tomcat: servlet-api.jar, jasper.jar, coyote.jar, jsp-api.jar etc.)
  • System class loader: Loads classes from the classpath, but the classpath is truncated by tomcat, so it doesn’t do anything except looking for CATALINA_HOME/bin/bootstrap.jar (tomcat startup), tomcat-juli.jar (logging) and tools.jar (for the jsp compiler).
  • Extention class loader (JAVA_HOME/jre/lib/ext)
  • Bootstrap class loader
  • Endorsed Standards Override Mechanism (the Endorsed Standards Override Mechanism lets you place overrides to certain classes (CORBA and JAXP classes) in the JAVA_HOME/lib/ endorsed folder. The Bootstrap loader will then load these preferentially over any classes that it might otherwise find. For details on this mechanism, see http://java.sun.com/j2se/1.5.0/docs/guide/standards/, Source : Tomcat 6 developer’s Guide, by Damodar Chetty)

When you try to load a class in a tomcat webapp, your default classloader first delegate to the standard class loader hierarchy :

  • the bootstrap serves up core classes.
  • extension loader : classes held within any installed extensions jar.
  • system class loader : catalina startup classes as well as supported classes.

If the class can’t be found, the webapp looks within its own repositories

  • from /WEB-INF/classes folder
  • from /WEB-INF/LIB/*.jar

If the class is still not found, the webapp delegate to it’s parent classloaser :

  • from %CATALINA_HOME%/lib/*.jar (common to all webapps, and internal tomcat classes)
  • the shared class loader : serves up classes that are common across all web appart within a given host.

More details on CLASS LOADER and how class loader WORKS

FROM HERE

The Java 2 delegation model cannot be followed in all situations. There are cases in which ClassLoaders have to diverge from the Java 2 model. For instance, the servlet specification recommends (section 9.7) that a Web application ClassLoader be implemented so that classes and resources packaged in the Web application archive are loaded in preference to classes and resources residing in container-wide JAR files. To meet this recommendation, a Web application ClassLoader should search for classes and resources in its local repository first, before delegating to a parent ClassLoader, thus deviating from the Java 2 delegation model. This recommendation makes it possible for Web applications to use different versions of classes/resources than those being used by a servlet container. For example, a Web application might be implemented using features available in a newer version of an XML parser than the one being used by a servlet container.

A Web application ClassLoader that meets the recommendation of the servlet specifications can be implemented by overriding the loadClass method of the java.lang.Classloader class. The loadClass method of such a custom ClassLoader may look similar to

 public Class loadClass(String name)throws ClassNotFoundException
 {    
    //check if the class is already loaded
    Class loadedClass = findLoadedClass(name);
    if (loadedClass == null) {
     //search for class in local repository before delegating
     .......      
     //if class not found delegate to parent
     loadedClass = this.getClass().getClassLoader().loadClass(name);
    }
    return loadedClass;
}

FROM HERE

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s