2011-07-05 26 views
77

Soy nuevo en Tomcat. Tenemos una máquina de desarrollo con aproximadamente 5 aplicaciones ejecutándose. A pesar de que es dev, nuestros clientes lo utilizan bastante durante las pruebas.¿Cómo actualizo una aplicación web Tomcat sin reiniciar todo el servicio?

Digamos que tenemos que hacer un pequeño cambio en un archivo de clase. En este momento, tenemos que cerrar Tomcat (que afecta a las otras cuatro aplicaciones), eliminar el archivo WAR (y el directorio de la aplicación web), volver a desplegar el nuevo archivo WAR y reiniciar Tomcat.

Por supuesto, esto molesta a algunas personas porque destruye todas las sesiones registradas para todas las aplicaciones.

¿Hay una mejor manera de hacerlo? Quiero decir, ¿hay alguna manera de volver a cargar solo la CLASE que cambió en lugar de todo en la máquina de desarrollo?

Gracias.

+0

Cambie su gestión de sesiones a algo que persiste a presentar? Lo siento no pude resistir :) – rogerdpack

+0

@rogerdpack He aprendido mucho sobre Tomcat desde que hice esta pregunta hace más de seis años. Pero gracias de cualquier manera. – cbmeeks

+0

En cuanto a las clases de intercambio directo, consulte https://stackoverflow.com/questions/32459047/how-to-enable-hot-deploy-in-tomcat – rogerdpack

Respuesta

49

¿Ha intentado utilizar Tomcat's Manager application? Le permite deshacer/desplegar archivos de guerra sin cerrar Tomcat.

Si no desea utilizar la aplicación Manager, también puede eliminar el archivo war del directorio webapps, Tomcat anulará la implementación de la aplicación después de un corto período de tiempo. A continuación, puede copiar un archivo war en el directorio y Tomcat desplegará el archivo war.

Si está ejecutando Tomcat en Windows, es posible que necesite configure su contexto para no bloquear varios archivos.

Si no puede tener ningún tiempo de inactividad, es posible que desee consultar Tomcat 7's Parallel deployments Puede implementar varias versiones de una aplicación web con la misma ruta de contexto al mismo tiempo. Las reglas utilizadas para hacer coincidir las solicitudes con una versión de contexto son las siguientes:

  • Si no hay información de sesión presente en la solicitud, utilice la última versión.
  • Si la información de sesión está presente en la solicitud, verifique el administrador de sesión de cada versión para una sesión coincidente y, si encuentra una, use esa versión.
  • Si la información de sesión está presente en la solicitud pero no se puede encontrar ninguna sesión coincidente, utilice la última versión.
+0

Esa es una buena sugerencia también. Nunca supe de la aplicación de administrador hasta hoy. Sí, usamos Windows. Una de las preocupaciones que tengo al eliminar el archivo WAR y esperar es que nuestros clientes esperen "pequeñas correcciones" con frecuencia. ¿Funcionarían esas sugerencias para ese escenario? – cbmeeks

+1

@cbmeeks - Depende de la frecuencia con que ocurran estas pequeñas correcciones, y cuánto tiempo antes de que alguien se dé cuenta. En cualquier caso, habrá una pequeña cantidad de tiempo para que la aplicación no esté disponible. Depende de su hardware/aplicación cuánto tiempo sea ese. Pero se mide en segundos, normalmente diría 5-10 en nuestras aplicaciones. Pero su kilometraje puede variar :) –

+0

@SteveK Estoy usando tomcat + IIS, por lo que las aplicaciones web implementadas están en diferentes contextos (diferentes sitios web) y definitivamente no dentro de la carpeta webapps de tomcat y, por lo tanto, la aplicación manager no puede verlas. Alguna solución ? –

3
+0

Ese material de JRebel parece un ganador. Esperaba una técnica gratuita, pero dado que el tiempo es dinero, la gerencia de aquí podría surgir para eso. ¿Encuentra que el costo vale la recompensa? Probablemente tenemos 3 instancias de JVM en 2 servidores. Gracias – cbmeeks

+3

, aunque esta es una vieja pregunta: he descubierto que JRebel NO vale realmente su dinero, solo ahorra unos segundos y tiene pequeñas ventajas sobre la implementación en caliente. Donde falle la implementación/recarga caliente, JRebel tampoco hace un mejor trabajo, de hecho tuve algunos errores adicionales extraños debido al "agente" de JRebel (reloader-daemon) ... este software solo puede valer la pena si tú " Estoy haciendo MUCHOS reintegros y/o pruebas locales, lo cual podría ser solo un signo de un proceso de trabajo defectuoso ... solo digo. – specializt

19

En el directorio conf de apache tomcat puede encontrar el archivo context.xml. En esa etiqueta de edición como < Contexto recargable = "true">. esto debería resolver el problema y no es necesario reiniciar el servidor

16

Hay varias maneras fáciles.

  1. Simplemente toque web.xml de cualquier aplicación web.

    touch /usr/share/tomcat/webapps/<WEBAPP-NAME>/WEB-INF/web.xml 
    

También puede actualizar un archivo jar en particular en WEB-INF/lib y luego toque web.xml, en lugar de construir archivo de la guerra entera y desplegar de nuevo.

  1. Eliminar directorio webapps/YOUR_WEB_APP, Tomcat se iniciará el despliegue de la guerra dentro de 5 segundos (asumiendo que su archivo de la guerra todavía existe en la carpeta de aplicaciones web).

  2. En general, sobrescribir el archivo war con la nueva versión se vuelve a implementar automáticamente mediante tomcat. De lo contrario, puede tocar web.xml como se explicó anteriormente.

  3. Copy sobre un ya explotó "directorio" en la carpeta de aplicaciones web

+1

Es útil saber que el método 'táctil' no vuelve a cargar las clases. IOW, no purga ni recarga la jerarquía del cargador de clases para la aplicación web – Rondo

+2

Al ver por qué esto funciona puede leerse en '$ CATALINA_BASE/conf/context.xml'. El WEB-INF/web.xml se mira para ver si hay cambios. Otros recursos se pueden enumerar fácilmente allí según sea necesario. – Kevin

Cuestiones relacionadas