It's always hard to remember tomcat class loader order !
You'll find here a complete resume :)
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.