deployment - change - ¿Por qué tomcat reemplaza context.xml en redesplegar?

tomcat context.xml example

Question

La documentación dice si tienes un archivo de contexto aquí:

$CATALINA_HOME/conf/Catalina/localhost/myapp.xml

NO será reemplazado por un archivo de contexto aquí:

mywebapp.war/META-INF/context.xml

Está escrito aquí: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

Solo si un archivo de contexto no existe para la aplicación en $ CATALINA_BASE / conf / [nombre de programa] / [nombre de host] /, en un archivo individual en /META-INF/context.xml dentro de los archivos de la aplicación.

¡Pero cada vez que vuelvo a desplegar la guerra, reemplaza este myapp.xml con /META-INF/context.xml!

¿Por qué lo hace y cómo puedo evitarlo?

Gracias

Answer 1

Despliegue parte de la aplicación de eliminación de redespliegues y el contexto asociado.xml.

Si usa el plugin maven tomcat, puede evitar eliminar context.xml si implementa su aplicación con un comando como este:

mvn tomcat:deploy-only -Dmaven.tomcat.update=true

Más información aquí: http://mojo.codehaus.org/tomcat-maven-plugin/deploy-only-mojo.html

Puede usar deploy-only con modo parámetro para implementar el contexto.xml también.

Answer 2

En tomcat7, también con autoDeploy = false, el archivo se eliminará al anular la implementación. Esto está documentado y no es un error (aunque evita las buenas implementaciones automatizadas con la configuración fija del lado del servidor).

Encontré una solución que me solucionó el problema:

• crea un archivo META-INF / context.xml en tu aplicación web que contiene
• en el servidor, cree un segundo contexto "/ config-context" en server.xml y coloque allí todos los parámetros de configuración del lado del servidor
• en la aplicación use context.getContext ("/ config-context"). getInitParameter (...) para acceder a la configuración allí.

Esto permite una configuración por host que es independiente de la guerra implementada.

También debería ser posible agregar configuraciones por contexto agregando contextos como "/ config-context-MYPATH". En su aplicación, puede usar la ruta de contexto de la aplicación para calcular la ruta de contexto de la aplicación de configuración.

Answer 3

La respuesta corta:

Simplemente haga que el directorio TOMCATHOME / conf / Catalina / localhost sea de solo lectura, y siga leyendo para obtener más detalles:

• Para el modo de implementación rápida (proyecto web dinámico Eclipse, conexión directa Tomcat, etc.) en un servidor Tomcat local / no compartido, puede simplemente definir su fuente de datos JDBC (o cualquier otro ''recurso web'') utilizando el contexto META-INF /. archivo xml dentro del archivo WAR. Fácil y rápido en su entorno local, pero no es adecuado para puesta en escena, control de calidad o producción.

• Para el modo de implementación de la compilación (por lo general, para etapas, QA o prod), los datos de JDBC y otros detalles de ''recursos web'' están definidos por el equipo de control de calidad / producción, no por el equipo de desarrollo. Por lo tanto, deben especificarse en el servidor Tomcat, no dentro del archivo WAR nunca más. En este caso, especifíquelos en el archivo TOMCATHOME / conf / Catalina / localhost / CONTEXT.xml (cambie Catalina por el motor y localhost por el host, y CONTEXT por su contexto en consecuencia). Sin embargo, Tomcat eliminará este archivo en cada implementación. Para evitar esta eliminación, simplemente haga este dir de solo lectura; en Linux puedes escribir:

     chmod a-w TOMCATHOME/conf/Catalina/localhost

  Voila! De nada.

La respuesta larga

• Por razones históricas, Tomcat le permite definir recursos web (fuentes de datos JDBC y otros) en cuatro lugares diferentes (leer cuatro archivos diferentes) en un orden de precedencia muy específico, si define el mismo recurso varias veces. Los que se mencionan en la respuesta breve anterior son los más adecuados hoy en día para cada propósito, aunque todavía puede usar los otros (nah ... probablemente no quiera). No voy a discutir los otros aquí a menos que alguien lo pida.

Answer 4

De acuerdo con la documentación ( http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files ) al volver a implementar tomcat detecta la eliminación (anulación) de su aplicación. Por lo tanto, comenzará un proceso de limpieza eliminando también el directorio y xml. Esto es independiente de la implementación automática, por lo que ocurrirá al volver a implementarse a través del administrador y también a la modificación de la guerra. Hay 3 excepciones:

• los recursos globales nunca se eliminan
• los recursos externos nunca se eliminan
• si WAR o DIR se han modificado, el archivo XML solo se elimina si copyXML es verdadero y deployXML es verdadero

No sé por qué, pero copyXML = "false" deployXML = "false" no ayudará.

En segundo lugar: hacer que el directorio solo sea leído hace que tomcat arroje una excepción y no se inicie.

Puede intentar fusionar sus archivos $ CATALINA_BASE / conf / Catalina / localhost / myapp-1.xml, $ CATALINA_BASE / conf / Catalina / localhost / myapp-2.xml, etc. en $ CATALINA_BASE / conf / context.xml (que solo funciona si se asegura de que su aplicación no despliegue su propia configuración de contexto, como myapp-1.xml)

Si alguien pudiera decir qué son esos "recursos externos" que generalmente resolverían el problema.

Answer 5

Redespliegue significa dos partes: el despliegue y la implementación.

La desinstalación elimina conf/Catalina/yourhost/yourapp.xml porque el

 <Host name="localhost" appBase="webapps" unpackWARs="true" 

           autoDeploy="true">      <!-- means autoUndeploy too!!! -->

 </Host>

Cambia la autoDeploy="false" y Tomcat ya no tiene orden para eliminar conf/Catalina/yourhost/yourapp.xml .