Order of Tomcat Classloaders: common, shared, and server
Agree with mindas, apache tomcat group might be considering deprecate server&shared classloader. About the order of webappclassloader and standardclassloader(common class loader), there is an interesting post done by Jianbo. He did a simple test to demonstrate it. http://web.archive.org/web/20120303091507/http://www.jianbozhu.net/2012/02/14/tomcat-classloader-demonstration/
Basically the gist of it is that in tomcat, the classloader loads classes from webapp first, then shared/common, then system.
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.
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.