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


24

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


Tem esse problema para. Parece que quando você substitui sua guerra, isso causa a remoção do aplicativo, o que causa a exclusão do arquivo de contexto. Eu não tenho uma solução alternativa, mas adoraria ter um que é mais conveniente do que reloadable = false stackoverflow.com/questions/4032773/...
artemb

Respostas:


18

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


Esta não é uma resposta completa - consulte serverfault.com/faq#deletion
Jenny D diz Reinstate Monica

:) Por favor, ajudar a si mesmo (parece a sintaxe destacando obras ligeiramente diferentes do que em stackoverflow que suprimiu parte da resposta antes)
Jan Zyka

O fato é que, se você apenas adicionar um link, o destino do link poderá desaparecer, tornando a resposta inútil. É por isso que serverfault.com incentiva você a postar a resposta real em vez de apenas o link. E quando eu comentei, o restante do texto não estava visível. Eu ainda recomendaria realmente postar uma resposta mais completa do que um breve resumo do link.
Jenny D diz Restabelecer Monica

1
Isso simplesmente não é verdade. A resposta original continha (e ainda contém) um breve resumo do que você pode encontrar no link. Sem o link, a resposta ainda faz todo o sentido e, junto com o link, você pode encontrar detalhes.
Jan Zyka

Mas eu não planejava ser ofensivo, desculpe se soasse assim :) Não gosto muito dessa web, apenas resolvi o mesmo e queria compartilhar.
Jan Zyka

5

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 .


2

Não posso responder a parte Por que .

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


1
Sob tomcat7, autoDeploy = "false" não faz diferença :(
Joseph Lust

1

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


Infelizmente, isso dificulta o desenvolvimento, pois eu teria que reiniciar o Tomcat após cada compilação.
staticsan

check-out jrebel para ajudar com isso no desenvolvimento: zeroturnaround.com/jrebel
harmanjd

0

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


0

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.


-1

À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á.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.