¿Por qué a tomcat le gusta eliminar mi archivo context.xml?


24

Estoy desarrollando una aplicación Java basada en la web en el trabajo y (obviamente) tengo que ejecutarla localmente durante el desarrollo. He descubierto los documentos de Tomcat y tengo un archivo context.xml adecuado, /etc/tomcat6/Catalina/localhost/pero de vez en cuando, ¡Tomcat decide eliminarlo! Lo que significa que tengo que volver a ponerlo y reiniciar Tomcat.

¿Por qué hace esto? He buscado en los documentos de Tomcat al respecto y no soy el más sabio.

(Oh, sí: en realidad no se llama, context.xmlpero owners.xmlcomo ese es el prefijo de ruta HTTP para esta aplicación).

Actualizar

Ahora he visto a Tomcat eliminar el archivo mientras Tomcat se estaba ejecutando . Creo que necesito presentar un error ...


Tener este problema para Parece que cuando reemplazas tu guerra, esto provoca el despliegue de la aplicación, lo que provoca la eliminación del archivo de contexto. No tengo una
solución alternativa,

Respuestas:


18

Resumen rápido : existen varias condiciones (como cambiar el archivo war, eliminar la aplicación web o reemplazarlo con contenido nuevo) en las que tomcat desplegará el contexto, incluida la eliminación del archivo contextual.

Detalles : si tomcat hace o no autoDeployment (significa verificar los cambios en su descriptor .xml, así como verificar los cambios en el directorio de la aplicación web) está determinado por:

  1. server.xml localizado en la sección $ CATALINA_HOME / conf / server.xml:

    <Nombre de host = "localhost" appBase = "webapps" unpackWARs = "true" autoDeploy = "true" xmlValidation = "false" xmlNamespaceAware = "false">

  2. También puede establecer esta propiedad en su archivo de contexto sobrecargando el valor

Citar el documento para los casos en que autoDeploy = true puede causar la eliminación de su archivo de contexto:

  • La eliminación de un archivo WAR desencadenará la eliminación de la aplicación con la eliminación de cualquier directorio expandido asociado, archivo de contexto y directorio de trabajo.
  • Eliminar un directorio desencadenará una cancelación de la implementación de la aplicación con la eliminación de cualquier archivo de contexto asociado y directorio de trabajo.
  • La actualización de un archivo WAR desencadenará la eliminación de la aplicación con la eliminación de cualquier directorio expandido asociado, archivo de contexto y directorio de trabajo.
  • La actualización de un directorio (no el contenido del directorio) desencadenará una cancelación de la implementación de la aplicación con la eliminación de cualquier archivo de contexto asociado y directorio de trabajo.

Detalles exhaustivos : http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment


Esta no es una respuesta completa: consulte serverfault.com/faq#deletion
Jenny D dice Reinstate Monica

:) por favor ayúdate (parece que el resaltado de sintaxis funciona ligeramente diferente que en stackoverflow que eliminó parte de la respuesta antes)
Jan Zyka

La cuestión es que si solo agrega un enlace, el objetivo del enlace puede desaparecer, haciendo que la respuesta sea inútil. Es por eso que serverfault.com lo alienta a publicar la respuesta real en lugar de solo el enlace. Y cuando comenté, el resto del texto no era visible. Todavía recomiendo publicar una respuesta más completa en lugar de un breve resumen del enlace.
Jenny D dice Restablecer a Monica

1
Eso simplemente no es cierto. La respuesta original contenía (y aún contiene) un breve resumen de lo que puede encontrar debajo del enlace. Sin el enlace, la respuesta todavía tiene mucho sentido y, junto con el enlace, puede encontrar detalles.
Jan Zyka

Pero no pensaba ser ofensivo, lo siento mucho si sonara así :) No me gusta mucho esta web, solo estaba resolviendo lo mismo y quería compartir.
Jan Zyka

5

Si no desea la función autoDeploy , por ejemplo, en entornos de producción, puede considerar los siguientes atributos en el archivo de contexto conf / Catalina / localhost:

  • autoDeploy = "false"
  • y deployXML = "false"

autoDeploy = "false" puede no funcionar solo porque la aplicación context.xml (en META-INF) puede anular la configuración de server.xml de autoDeploy.

  • El META-INF / context.xml de la aplicación se usará en el entorno de desarrollo, con autoDeploy
  • El contexto conf / Catalina / localhost en producción, sin autoDeploy.

Vale la pena leer la documentación del atributo deployXML (§ Implementación estándar).

Exhaustivo caso de usuario AutoDeploy, y cuando se elimina el contexto: es decir, la aplicación no implementada, el caso de usuario documentado se puede encontrar aquí .


2

No puedo responder el por qué .

Sin embargo, este enlace indica que puede detener esta ajustando el autoDeploy="false"deserver.xml


1
Bajo tomcat7 autoDeploy = "false" no hace ninguna diferencia :(
Joseph Lust

1

Sinceramente, no sé cuál es el razonamiento detrás de Tomcat haciendo esto, pero intente agregar el siguiente atributo XML a su elemento de contexto

reloadable="false"

Entonces su contexto podría verse más o menos así:

<Context path="/" docBase="/some/path/name" reloadable="false">
<!-- Context related stuff -->
</Context>

Esto debería evitar que Tomcat elimine el archivo


Desafortunadamente, eso dificulta el desarrollo ya que tendría que reiniciar Tomcat después de cada compilación.
staticsan

checkout jrebel para ayudar con esto en el desarrollo: zeroturnaround.com/jrebel
harmanjd

0

Me doy cuenta de que este es un hilo viejo, pero pensé que compartiría lo que encontré para solucionar este problema ...

Había tenido exactamente el mismo problema con mi archivo context.xml para mi versión de escritorio de tomcat que se apagaba cada vez que desplegaba una nueva copia del archivo war para mi aplicación.

El problema se debió al hecho de que estaba haciendo cambios a este archivo directamente en el sistema de archivos. Lo que solucionó el problema fue editar el archivo context.xml a través de mi editor Eclipse. Dentro de mi Eclipse, hay un proyecto de "servidores" que una vez que lo expande, puede ver un puñado de archivos, como context.xml y server.xml. Parece que si modifica los archivos desde aquí en lugar de salir al sistema de archivos, sus cambios se mantienen.

Encontré esta solución en el siguiente hilo: https://www.liferay.com/community/forums/-/message_boards/message/16511799

¡Espero que esto ayude a alguien más!

-StephenS


0

El problema general, tal como se describe en el título, está cubierto por Re-deploy from war sin eliminar el contexto, que todavía es un problema abierto en este momento.

Existe una distinción reconocida entre volver a implementar que no elimina el contexto, y desplegar después de desinstalar donde la desinstalación elimina el contexto. La documentación estaba desactualizada y la GUI del administrador aún no admite la reinstalación.


-1

A veces es necesario tener valores diferentes para la aplicación en el servidor, por ejemplo, una ruta para almacenar archivos cargados. En el entorno de desarrollador mabe tenemos algo como esto:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" reloadable="false">
     <Parameter name="rutaTrabajo" value="C:\Larry\Proyectos\app\rutaTrabajoxx" override="true"/>
</Context>

Pero en el servidor la ruta es diferente:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/App/rutaTrabajo" override="true"/>
</Context>

También tengo el mismo problema, tomcat eliminando el context.xml (meapp.xml) de conf / Catalina / localhost

Para resolverlo, uso context.xml.default, en la misma ruta creo un archivo llamado context.xml.default y dentro de una configuración put que quiero contener:

 cat context.xml.default
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/ParkiMeApp/rutaTrabajo" override="true"/>
</Context>

Entonces, al volver a implementar la aplicación, los parámetros de confirmación siguen ahí.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.