2009-09-07 23 views
12

¿Se pueden implementar archivos JAR en caliente en Tomcat 5? La idea es evitar reiniciar Tomcat y aún así poder cargar (a través de la reflexión) alguna clase de un JAR recién agregado. ¿Se puede hacer? ¿Cómo? ¿No es recomendable para un sistema de producción? GraciasTomcat: implementación en caliente de nuevas jarras

Editar: mi escenario requiere la adición de nuevos archivos JAR cuyos nombres no se conocen de antemano. ¿Puede el servidor "mirar" un directorio de JAR en lugar de JAR específicos?

Respuesta

9

Sí, es posible. A few tricks from the Tomcat stable, en el supuesto de que el despliegue automático se enciende:

  1. Si un archivo WAR no tiene un directorio correspondiente, que se ampliará y desplegado automáticamente.
  2. Los cambios en WEB-INF \ web.xml causarán una recarga de la aplicación.
  3. Actualizaciones para explotó archivos WAR causarán una redistribución
  4. Los cambios en los archivos de configuración XML se supone que causa una redistribución

Por supuesto, esto no es recomendable para los sistemas de producción. No es que esta característica sea defectuosa, pero las aplicaciones pueden estar mal codificadas para no limpiar los recursos o descargar clases en el momento del despliegue. Esto dará como resultado ciertas clases restantes en la memoria. Cuando se vuelva a implementar la versión más nueva de la aplicación, se encontrarán errores imprecisos debido a que la versión anterior de las clases está presente. Los singletons mal escritos, a menudo son la mayor causa de este problema.

El protocolo que sigo, para evitar problemas similares es anular la implementación de la aplicación, derribar Tomcat, verificar la 'cordura' de los directorios del sistema de archivos de Tomcat, eliminar los recursos que quedan, reiniciar la instancia de Tomcat y volver a implementar la solicitud. Se ve un poco pesado, pero me han quemado lo suficiente.

11

Tomcat no proporciona ningún mecanismo para volver a cargar un solo JAR. Sin embargo, todo el contexto se puede volver a cargar.

sólo tiene que decirle a Tomcat para observar su JAR en context.xml, de esta manera,

<?xml version="1.0" encoding="UTF-8"?> 
<Context override="true" swallowOutput="true" useNaming="false"> 
    <WatchedResource>WEB-INF/web.xml</WatchedResource> 
    <WatchedResource>WEB-INF/lib/your.jar</WatchedResource> 
    <Manager pathname=""/> 
</Context> 

Hacemos esto en la producción. Tomcat solía tener algunas pérdidas de memoria, pero no hemos encontrado ningún problema con Tomcat 5.5 o posterior.

No sé si todavía es necesario. Tenemos que hacer las siguientes llamadas para evitar la pérdida de memoria durante la implementación en caliente.

public void contextDestroyed(ServletContextEvent sce) { 
     // To fix the known memory leaks during re-deploy 
     ClassLoader contextClassLoader = 
      Thread.currentThread().getContextClassLoader(); 
     LogFactory.release(contextClassLoader); 

     java.beans.Introspector.flushCaches(); 
     ... 
    } 
+0

+1 para la llamada a LogFactory.release(). Aunque no utilizo Apache Commons Logging, es un código como este que aumenta la confianza en una aplicación. Más información @http: //wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak –

+0

Gracias chicos ... por favor revisen la edición en OP. –

Cuestiones relacionadas