Por que o tomcat gosta de excluir meu arquivo context.xml?

Question

Estou desenvolvendo um aplicativo Java baseado na web no trabalho e (obviamente) tenho que executá-lo localmente durante o desenvolvimento. Eu descobri os documentos do Tomcat e tenho um arquivo context.xml adequado em /etc/tomcat6/Catalina/localhost/ , mas de vez em quando, o Tomcat decide excluí-lo! O que significa que eu tenho que colocá-lo de volta e reiniciar o Tomcat.

Por que isso acontece? Eu pesquisei os documentos do Tomcat sobre isso e não sou o mais sábio.

(Ah sim: na verdade não é chamado context.xml mas owners.xml , pois esse é o prefixo do caminho HTTP para este aplicativo.)

Atualizar

Eu já vi o Tomcat excluir o arquivo enquanto o Tomcat estava sendo executado . Eu acho que preciso registrar um bug ...

    

Answer 1

Resumo rápido : há várias condições (como alterar o arquivo war, excluir o webapp ou substituí-lo por um novo conteúdo) sob o qual o tomcat desimplementará o contexto, incluindo a remoção do arquivo de contexto.

Detalhes : Se o tomcat faz ou não o autoDeployment (significa verificar as alterações no seu descritor .xml, bem como verificar as alterações no diretório do webapp) é orientado por:

1. server.xml localted na seção $ CATALINA_HOME / conf / server.xml:

   < Nome do host="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="falso" xmlNamespaceAware="false" >

2. Você também pode definir essa propriedade em seu arquivo de contexto sobrecarregando o valor

Citando o documento para casos em que autoDeploy = true pode causar a remoção do seu arquivo de contexto:

• A exclusão de um arquivo WAR acionará uma remoção do aplicativo com a remoção de qualquer diretório expandido associado, arquivo de contexto e diretório de trabalho.
• A exclusão de um diretório acionará uma remoção de implementação do aplicativo com a remoção de qualquer arquivo de contexto associado e o diretório de trabalho.
• A atualização de um arquivo WAR acionará uma remoção de implementação do aplicativo com a remoção de qualquer diretório expandido associado, arquivo de contexto e diretório de trabalho.
• A atualização de um diretório (não o conteúdo do diretório) acionará uma remoção de implementação do aplicativo com a remoção de qualquer arquivo de contexto associado e o diretório de trabalho.

Detalhes exaustivos : link

    

Answer 2

Se você não deseja o recurso autoDeploy , em ambientes de produção, por exemplo, poderá considerar os seguintes atributos no arquivo de contexto conf / Catalina / localhost:

• autoDeploy="false"
• e deployXML="false"

autoDeploy="false" pode não funcionar sozinho porque o aplicativo context.xml (no META-INF) pode substituir as configurações de server.xml do autoDeploy.

• O META-INF / context.xml do aplicativo será usado no ambiente de desenvolvimento, com o autoDeploy
• O contexto conf / Catalina / localhost em produção, sem autoDeploy.

A documentação do atributo documentação do atributo deployXML vale a pena ser lida (§ Padrão Implementação).

Exemplo de usuário de autoDeploy exaustivo e quando o contexto é removido: ou seja, o aplicativo não implantado, o caso do usuário é documentado, pode ser encontrado aqui .

    

Answer 3

Não é possível responder ao bit Por que .

No entanto, Este link indica que você pode interromper este definindo o autoDeploy="false" em server.xml

    

Answer 4

Eu sinceramente não sei qual é o raciocínio por trás do Tomcat fazendo isso, mas tente adicionar o seguinte atributo XML ao seu elemento de contexto

reloadable="false"

Assim, seu contexto pode ser algo assim:

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

Isso deve impedir que o Tomcat exclua o arquivo

    

Answer 5

Às vezes, é necessário ter valores diferentes para o aplicativo no servidor, por exemplo, um caminho para armazenar os arquivos enviados. No ambiente de desenvolvimento do mabe, temos algo assim:

<?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>

Mas no servidor, o caminho é 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>

Eu também tenho o mesmo problema, tomcat excluindo o context.xml (meapp.xml) de conf / Catalina / localhost

Para resolver eu uso context.xml.default, no mesmo caminho eu crio um arquivo chamado context.xml.default e dentro de uma put put eu quero segurar:

 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>

Assim, ao reimplantar o aplicativo, os parâmetros de confirmação ainda estarão lá.

    

Answer 6

Eu sei que este é um tópico antigo, mas pensei em compartilhar o que encontrei para corrigir esse problema ...

Eu estava tendo exatamente o mesmo problema com o meu arquivo context.xml para a minha versão de desktop do tomcat sendo atacado toda vez que eu implantava uma nova cópia do arquivo war do meu aplicativo.

O problema foi devido ao fato de que eu estava fazendo alterações neste arquivo diretamente no sistema de arquivos. O que corrigiu o problema foi editar o arquivo context.xml através do meu editor Eclipse. Dentro de No meu Eclipse, há um projeto de "servidores" que, depois de expandido, você pode ver alguns arquivos, como context.xml e server.xml. Parece que se você modificar os arquivos daqui em vez de sair para o sistema de arquivos, suas alterações são mantidas.

Eu encontrei esta solução no seguinte tópico: link

Espero que isso ajude alguém!

-StephenS