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

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, /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 ele faz isso? Eu pesquisei os documentos do Tomcat sobre isso e não sou o mais sábio.

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

Atualizar

Agora eu vi o Tomcat excluir o arquivo enquanto o Tomcat estava em execução . Eu acho que preciso registrar um bug ...

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

Detalhes : se o tomcat executa ou não o autoDeployment (significa verificar alterações no seu descritor .xml, bem como verificar alterações no diretório webapp) é conduzido por:

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

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

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

Citar 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á a remoção da implementaçã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á a remoção da implementação do aplicativo com a remoção de qualquer arquivo de contexto associado e diretório de trabalho.
• A atualização de um arquivo WAR acionará a remoção da 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á a remoção da implementação do aplicativo com a remoção de qualquer arquivo de contexto associado e diretório de trabalho.

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

Se você não deseja o recurso autoDeploy , em ambientes de produção, por exemplo, considere 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 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.

documentação do atributo deployXML vale a pena ler a atributo (§ Implementação padrão).

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

Não posso responder a parte Por que .

No entanto, Este link afirma você pode parar isso definindo o autoDeploy="false"emserver.xml

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

reloadable="false"

Portanto, seu contexto pode ser algo como isto:

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

Isso deve impedir o Tomcat de excluir o arquivo

Sei que esse é 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 desktop do tomcat sendo derrotada toda vez que implantava uma nova cópia do arquivo war para o meu aplicativo.

O problema ocorreu devido ao fato de eu estar fazendo alterações nesse arquivo diretamente no sistema de arquivos. O que resolveu o problema foi editar o arquivo context.xml através do meu editor Eclipse. Dentro do meu Eclipse, há um projeto de "servidores" que, quando você o expande, 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 serão mantidas.

Encontrei esta solução no seguinte segmento: https://www.liferay.com/community/forums/-/message_boards/message/16511799

Espero que isto ajude alguém!

-StephenS

O problema geral descrito no título é coberto por Reimplantar da guerra sem excluir o contexto, que ainda é um problema em aberto no momento.

Há uma distinção reconhecida entre reimplantar, que não exclui o contexto, e implantar após desimplementar, em que a desimplantação exclui o contexto. A documentação estava desatualizada e a GUI do gerente ainda não suporta a reimplantação.

Às vezes, é necessário ter valores diferentes para o aplicativo no servidor, por exemplo, um caminho para armazenar arquivos enviados. No ambiente de desenvolvedor mabe, temos algo parecido com isto:

<?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, o tomcat excluindo o context.xml (meapp.xml) de conf / Catalina / localhost

Para resolver eu uso context.xml.default, no mesmo caminho, crio um arquivo chamado context.xml.default e dentro de uma configuração put que quero manter:

 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>

Portanto, ao reimplementar o aplicativo, os parâmetros de confirmação ainda estão lá.