Não é possível implementar automaticamente a guerra no tomcat

2

Eu tenho experimentado essa coisa nas últimas 3 horas e nada. Eu preciso soltar uma nova guerra e ter o tomcat autodeploy. Isso não está acontecendo. Aqui está minha configuração simplificada:

server.xml

<Engine name="Catalina" defaultHost="localhost">
  <Host name="something.com" appBase="/var/www/something.com/webapps"
        unpackWARs="false" autoDeploy="true" 
        xmlValidation="false" xmlNamespaceAware="false">
    <Context path="" docBase="application.war" debug="0" reloadable="true">
      ... some realm and data source stuff here
    </Context>
  </Host>
</Engine>

Quando eu começo o tomcat, tudo funciona muito bem. Eu tentei duas abordagens:

  1. Copie uma nova guerra usando scp no local.
  2. Tocando /var/www/something.com/webapps/application.war .

Em ambos os casos, posso ver catalina.err com a mesma mensagem:

INFO: Undeploying context [/application]

Sem um correspondente

INFO: Deploying web application archive application.war

que eu recebo quando eu reinicio o tomcat. Eu tenho a sensação de que isso é porque não está dentro do CATALINA_BASE/webapps , mas não sei como proceder. Alguma ajuda?

    
por Ricardo Marimon 23.10.2010 / 00:59

5 respostas

2

Pode ser uma série de coisas. Alguns problemas específicos que eu atingi:

(1) Permissões de arquivo. Certifique-se de que o diretório webapps, seu diretório de trabalho, a guerra em si e quaisquer arquivos especiais acessados por ele sejam todos legíveis / graváveis pelo usuário que está executando o Tomcat (idealmente, eles devem pertencer a esse usuário).

(2) A versão anterior não foi totalmente removida. Tente parar o Tomcat, excluindo a pasta war and matching, copiando a nova guerra e iniciando o Tomcat. Se funcionar, o problema pode ser deixado por arquivos. (Eu tenho um aplicativo, por exemplo, que não se limpa completamente).

(3) O aplicativo pode não estar sendo inicializado corretamente devido a problemas com o aplicativo. Se a guerra implantar automaticamente em uma pasta, o autodeploy está funcionando, mas o aplicativo não foi totalmente inicializado. Procure por mensagens de log. Dependendo do seu aplicativo, isso pode estar no tomcat / logs, no diretório atual ou no padrão. Se puder, altere as propriedades do log (por exemplo, arquivo log4j.properties) para mostrar mensagens no nível de depuração.

(4) problemas de memoria do Permgen. Quando você recarrega um aplicativo no Tomcat, ele usa a memória Permgen. Por definição, isso não pode ser recuperado. Recarregue demais, e o Tomcat irá travar com um erro de falta de memória (você pode ver isso nos seus logs). Configure mais permgen ou, melhor ainda, desligue / reinicie o Tomcat ao reimplementar um aplicativo.

link

    
por 25.10.2010 / 04:24
0

Acho que o culpado é o unpackWARs="false"

De um postagem recente em stackoverflow , foi descoberto que unpackWARs="false" faz com que a nova versão do WAR não seja detectada. Qualquer motivo específico é false ?

    
por 25.10.2010 / 07:50
0

Não deveria ser docBase="application" não docBase="application.war" ? Se bem entendi, isso fará com que o Tomcat primeiro procure uma pasta /var/www/something.com/webapps/application/ e, se isso não existir, procure por /var/www/something.com/webapps/application.war

    
por 14.11.2012 / 21:24
0

Se você estiver usando maven , em pom.xml você pode definir uma tag como

<properties>
    <local.tomcat.autodeploy.folder>//pathtoTomcatWebapp folder</local.tomcat.autodeploy.folder>
            <local.build.finalName>nameOfContext</local.build.finalName>
            <localonly>true</localonly>

        <dev.tomcat.autodeploy.folder>specify location</dev.tomcat.autodeploy.folder>
        <dev.build.finalName>nameOfContext</dev.build.finalName>


</properties>
    
por 13.12.2017 / 11:49
0

Embora este seja um tópico antigo, eu só queria apontar uma coisa. No IDE, clique com o botão direito do mouse no servidor e procure por locais do servidor e selecione Usar a instalação do Tomcat. Isso assumirá o controle do local instalado e explodirá a guerra.

    
por 06.01.2018 / 01:32

Tags