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

documentación dice si tiene un archivo de contexto aquí:¿Por qué tomcat reemplaza context.xml en redesplegar?

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

no va a 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

Sólo si no existe un archivo de contexto para la aplicación en $ CATALINA_BASE/conf/[enginename]/[hostname] /, en un archivo individual en /META-INF/context.xml dentro de la aplicación fil es.

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

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

Thanx

Fuente

2010-10-27 artemb

¿Se está implementando manualmente o mediante un complemento IDE? – BalusC

Personalmente, no pondría un contexto.xml en el servidor de la aplicación. No lo hago porque rara vez dependo de tener acceso a ese archivo. Normalmente lo mantengo local en mi archivo WAR. – duffymo

Estoy implementando manualmente colocando mywebapp.war en $ CATALINA_HOME/webapps. Mantengo mis configuraciones predeterminadas en WAR, pero deseo poder cambiar esas configuraciones para cada instancia sin modificar la guerra en sí; es por eso que quiero que mi contexto en el directorio conf no cambie – artemb

Undeploy parte de redeploy elimina aplicación y la context.xml asociado.

Si utiliza Tomcat Maven plugin que puede evitar la eliminación de context.xml si implementa su aplicación con el comando de la siguiente manera:

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 utilizar desplegar sólo con modo de parámetro para implementar el contexto.xml también.

Fuente

2011-12-12 10:05:12 petro

Para gente que sigue en casa: 'mvn tomcat7: deploy-only -Dmaven.tomcat.update = true -Dmaven.tomcat.mode = both -Dmaven.tomcat.contextFile =/foo/context.xml' hace el truco. Triste ... pero efectivo en tomcat7. –

En tomcat7, también con autoDeploy = falso, 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 resolvió el problema para mí:

crear un archivo/context.xml META-INF en su aplicación web que contiene
en el servidor de crear un segundo contexto "/ config contexto "en server.xml y ponga todos sus parámetros de configuración del lado del servidor allí
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.

Fuente

2012-10-04 15:24:27

¿Por qué los desarrolladores centrales de tomcat ignoran la implementación de las mejores prácticas? Perdí básicamente una noche para encontrar una solución aquí y todo lo demás son anti-patrones, pero los desarrolladores de TC están en negación y no reconocerán que este es un enfoque sensato para instalar fuentes y fuentes JNDI en el host, no compilar ellos en el SCM y la guerra. https://issues.apache.org/bugzilla/show_bug.cgi?id=34840 –

La respuesta corta:

solo hago los TOMCATHOME/conf/Catalina/localhost dir de sólo lectura, y sigue leyendo para más detalles:

Para modo de implementación rápida (Proyecto web dinámico Eclipse, conexión directa Tomcat , etc.) en un servidor Tomcat local/no compartido, puede definir su fuente de datos JDBC (o cualquier otro 'recurso web' ) utilizando el META-INF/context.xml archivo dentro del archivo WAR . Fácil y rápido en su entorno local, pero no es adecuado para la producción por etapas, QA o .
Para el modo de despliegue acumulación (por lo general para la estadificación, control de calidad, o prod), JDBC fuentes de datos y detalles de otros recursos web '' están definidas por el equipo QA/producción, no el equipo de desarrollo más. Por lo tanto, se deben especificar en el servidor Tomcat, no dentro del archivo WAR . En este caso, especifique en el archivo TOMCATHOME/conf/Catalina/localhost/context.xml (modificar Catalina por el motor, y localhost por el anfitrión, y CONTEXTO por su contexto en consecuencia) . Sin embargo, Tomcat eliminará este archivo en cada implementación. Para evitar esta eliminación de , simplemente haga este dir de solo lectura; en Linux puede escribir:
```
chmod a-w TOMCATHOME/conf/Catalina/localhost 
```
Voila! De nada.

La respuesta larga

Por razones históricas Tomcat le permite definir los recursos web (fuentes de datos JDBC, y otros) en cuatro lugares diferentes (leer cuatro archivos diferentes) de una manera muy específica orden de precedencia, si define el mismo recurso varias veces. Las que se mencionan en la respuesta corta anterior son las más adecuadas hoy en día para cada propósito, aunque aún puede usar las demás (nah ... probablemente no desee). No voy a discutir los otros aquí a menos que alguien lo solicite.

Fuente

2015-03-19 18:00:06 user4691115

Lo preguntaré ;-) – djKianoosh

Esto no funcionará cuando la función de autodeploy esté activada para tomcat y use tomcat7: undeploy se quejará que no puede eliminar el archivo Descriptor de contexto – Chad

Con esta opción, mis implementaciones fallan con el mensaje de error 'No se puede invocar el gestor Tomcat: restablecimiento de conexión' por el motivo mencionado en el comentario de Chad. En cambio, utilicé la opción usando context.xml de WEB-INF y recurso jndi opcional (externo) del servidor.xml como se describe en la primera respuesta [aquí] (http://stackoverflow.com/questions/7142365/how-to-provide-a-context-configuration-for-a-web-application-in-tomcat) – tareq

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. Entonces 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:

recursos globales nunca se eliminan
recursos externos nunca se eliminan
si la guerra o DIR se ha modificado a continuación, el archivo XML solamente se elimina si copyXML es verdadera y deployXML es verdadero

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

En segundo lugar: Hacer que el directorio sea de solo lectura 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 (Eso 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.

Fuente

2015-11-10 22:45:58 BTakacs

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

desimplementación elimina la conf/Catalina/yourhost/yourapp.xml porque el cambio

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

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

</Host>

la autoDeploy="false" y Tomcat tiene ningún orden más para eliminar el conf/Catalina/yourhost/yourapp.xml.

Fuente

2017-02-15 22:25:01

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

Respuesta

Cuestiones relacionadas