Order of Tomcat Classloaders: common, shared, and server

Question

The Tomcat Class Loader HOW-TO documentation describes 4 different class loaders:

1. Bootstrap
2. System
3. Common
4. Webapp

In the default catalina.properties file, however, there are properties defined for a shared and server class loader as well. In the default version of the file both of these properties are empty and the comments say:

If left as blank, the "common" loader will be used as Catalina's "shared"/"server" loader.

I have not been able to find any additional documentation about these class loaders. My question is, in which order are the shared and system loaders searched relative to the common loader? And additionally, what is the intended use for these class loaders?

Answer 1

I recently ran into this issue as well and here is what I found, (This is all from Tomcat 7 trunk)

If left as blank, the "common" loader will be used as Catalina's "shared"/"server" loader.

Here is the relevant source,

89      private void initClassLoaders() {
90          try {
91              commonLoader = createClassLoader("common", null);
92              if( commonLoader == null ) {
93                  // no config file, default to this loader - we might be in a 'single' env.
94                  commonLoader=this.getClass().getClassLoader();
95              }
96              catalinaLoader = createClassLoader("server", commonLoader);
97              sharedLoader = createClassLoader("shared", commonLoader);
98          } catch (Throwable t) {
99              handleThrowable(t);
100             log.error("Class loader creation threw exception", t);
101             System.exit(1);
102         }
103     }

106     private ClassLoader createClassLoader(String name, ClassLoader parent)
107         throws Exception {
108 
109         String value = CatalinaProperties.getProperty(name + ".loader");
110         if ((value == null) || (value.equals("")))
111             return parent;

So if nothing is defined, they fallback to using the common.loader entries.

---

As to the order that they are loaded in, here is the source for loading them in, from source

229         Thread.currentThread().setContextClassLoader(catalinaLoader);
230 
231         SecurityClassLoad.securityClassLoad(catalinaLoader);
232 
233         // Load our startup class and call its process() method
234         if (log.isDebugEnabled())
235             log.debug("Loading startup class");
236         Class<?> startupClass =
237             catalinaLoader.loadClass
238             ("org.apache.catalina.startup.Catalina");
239         Object startupInstance = startupClass.newInstance();
240 
241         // Set the shared extensions class loader
242         if (log.isDebugEnabled())
243             log.debug("Setting startup class properties");
244         String methodName = "setParentClassLoader";
245         Class<?> paramTypes[] = new Class[1];
246         paramTypes[0] = Class.forName("java.lang.ClassLoader");
247         Object paramValues[] = new Object[1];
248         paramValues[0] = sharedLoader;
249         Method method =
250             startupInstance.getClass().getMethod(methodName, paramTypes);
251         method.invoke(startupInstance, paramValues);

Line 229 sets the common.loader classLoader, then line 251 sets the shared.loader classloader is set as Catalinas parent class loader.

Answer 2

Strange, Tomcat 5.5 classloader doc still has the shared loader documented but 6.0 doesn't; neither has v7.0 which you quote. Maybe they're going to deprecate it?

We do use shared loader extensively to override existing classes that came with the vanilla version of our software. The software we make comes in releases and to make a complete new release for one customer (which, say, requires a critical bugfix) is too expensive (re-testing everything, rebuilding, providing new documentation, new version number, etc.). So what we do instead is we provide a "hotfix" which goes into shared loader and overrides relevant .class in webapp.

Most often, "hotfix" is just a single class so the overall regression risk is minimal.

When our software gets upgraded, the upgrade removes the "hotfix" as the corrected code will also be present in the next version of our software itself.

I can also imagine other people using shared classloader for something that spawns across many different webapps.