2011-06-06 29 views
16

El Tomcat Class Loader HOW-TO documentación describe 4 cargadores de diferentes clases:Orden de Tomcat cargadores de clases: común y compartido, y el servidor

  1. Bootstrap
  2. sistema
  3. WEBAPP
  4. Común

En el archivo predeterminado catalina.properties, sin embargo, también hay propiedades definidas para un cargador de clases compartido y de servidor. En la versión predeterminada del archivo ambas de estas propiedades están vacías y los comentarios que dicen:

Si dejó como blanco, el cargador "común" será utilizado como cargador de Catalina "compartida"/"servidor".

No he podido encontrar ninguna documentación adicional sobre estos cargadores de clase. Mi pregunta es, ¿en qué orden se buscan los cargadores compartidos y del sistema en relación con el cargador común? Y, además, ¿cuál es el uso previsto para estos cargadores de clase?

+0

Vea también http://stackoverflow.com/questions/5474765/order-of-loading-jar-files-from-lib-directory – rogerdpack

Respuesta

9

poco me encontré con este tema, así y esto es lo que encontré, (Esto es todo desde Tomcat 7 tronco)

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

Aquí es el relevante 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; 

Por lo tanto, si no se define nada, recurren al uso de las entradas common.loader.


En cuanto al orden en que se cargan en, aquí es la fuente para cargarlos en, desde 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); 

Línea 229 conjuntos common.loader el cargador de clases, luego la línea 251 conjuntos de las El cargador de clases shared.loader se establece como el cargador de clases padre de Catalinas.

1

Strange, Tomcat 5.5 classloader doc todavía tiene el cargador shared documentado pero 6.0 doesn't; tampoco tiene v7.0 que cites. ¿Quizás lo van a desaprobar?

Usamos el cargador compartido ampliamente para anular las clases existentes que vienen con la versión estándar de nuestro software. El software que hacemos viene en versiones y para hacer una nueva versión completa para un cliente (que, por ejemplo, requiere una corrección de errores crítica) es demasiado caro (volver a probar todo, reconstruir, proporcionar nueva documentación, nuevo número de versión, etc.). Entonces, lo que hacemos en su lugar es que proporcionamos un "hotfix" que va al cargador compartido y anula el relevante .class en la aplicación web.

Más a menudo, la "revisión" es solo una clase, por lo que el riesgo de regresión general es mínimo.

Cuando nuestro software se actualiza, la actualización elimina la "revisión" ya que el código corregido también estará presente en la próxima versión de nuestro software.

También puedo imaginar a otras personas que usan el cargador de clases compartido para algo que se genera en muchas aplicaciones diferentes.

+1

Entonces, @mindas, usted está diciendo que el cargador de clases compartido se busca realmente antes el cargador de clases de aplicaciones web? Eso no parece correcto. –

1

De acuerdo con mindas, el grupo de apache tomcat podría estar considerando depreciar el servidor & cargador de clases compartido. Sobre el orden de webappclassloader y standardclassloader (cargador de clases común), hay una publicación interesante hecha por Jianbo. Hizo una prueba simple para demostrarlo. http://web.archive.org/web/20120303091507/http://www.jianbozhu.net/2012/02/14/tomcat-classloader-demonstration/

Básicamente, la esencia de esto es que en tomcat, el cargador de clases primero carga las clases de la aplicación web, luego comparte/común, luego el sistema.

Cuestiones relacionadas