Problema para reimplantar .war no tomcat

Programação Java
#1

Bom dia galera,

Estou com um problema recorrente em meu dia-a-dia.
Estou desenvolvendo um projeto J2EE, um site wap utilizando o VRaptor, e quando tento reimplantá-lo no tomcat em minha máquina (windows vista) ele dá o seguinte erro:

INFO: Undeploying context [/SiteWap]
08/11/2010 11:35:32 org.apache.tiles.servlet.context.ServletUtil setContainer
INFO: Removing TilesContext for context: org.apache.catalina.core.ApplicationContextFacade
08/11/2010 11:35:32 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1] (value [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1@2c5469]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
08/11/2010 11:35:32 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1] (value [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1@59f61b]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
08/11/2010 11:35:32 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1] (value [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1@2c93ed]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
08/11/2010 11:35:32 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1] (value [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1@a3eb45]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
08/11/2010 11:35:32 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1] (value [org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1@1ab0164]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
08/11/2010 11:35:33 org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive SiteWap.war
08/11/2010 11:35:33 org.apache.catalina.startup.ContextConfig init
SEVERE: Exception fixing docBase for context [/SiteWap] 
java.io.FileNotFoundException: C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\SiteWap\META-INF\MANIFEST.MF (Acesso negado)
	at java.io.FileOutputStream.open(Native Method)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:457)
	at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:173)
	at org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:882)
	at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1017)
	at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.StandardContext.init(StandardContext.java:5439)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4215)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)
	at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:905)
	at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:740)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:500)
	at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1345)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:303)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
	at java.lang.Thread.run(Unknown Source)

Para conseguir reimplantar eu preciso derrubar o tomcat excluir o arquivo .war e restartar o tomcat.
Isso toda vez que eu preciso reimplantá-lo.

Alguem tem alguma idéia do que está causando este erro?

#2

Realmente o hotdeploy do tomcat não funciona muito bem.
Uma alternativa seria usar um servidor de aplicações como o Glassfish. Nele o hotdeploy funciona perfeitamente. Em relação à outros servidores, com o JBoss, eu não posso te falar nada pq não tenho experiência.

[]´s

#3

David,
No JBoss eu posso estar fazendo errado, mas não consigo fazer funcionar muito bem também não (na verdade, eu não consegui fazer funcionar - deve ter algum jeito, mas não sei qual é).

Maruero,
Se for o problema de hotdeploy, o interessante é parar o servidor, fazer o deploy e iniciar novamente (mas aposto que você já sabia disso, né?). Eu já vi alguns colegas na faculdade conseguirem fazer hotdeploy no Linux, mas no Windows nunca tentei. Tento quando chegar do trabalho, em casa, a noite. Aliás, você diz deploy o ato de montar o .war, jogar na pasta webapps e o Tomcat mesmo descompactar, né?

Já tentou fazer como acontece no Google App Engine? O servidor que tem com o plugin pro Eclipse não pega o .war e descompacta, o desenvolvedor tem que colocar a pasta mesmo. No Tomcat também dá pra fazer assim, mas não sei se, nesse caso, ele aceitaria o hotdeploy.

#4

Já tive muito problema de redeploy de aplicação web e sempre tive problema no Windows, que aparentemente não consegue excluir alguns arquivos no momento do undeploy da aplicação.

Tive problemas com Sun Application Server(hoje Glassfish), JBoss e Tomcat. Todos do mesmo jeito, fica sujeira após excluir a aplicação e não consegue subir novamente. Nunca tive problemas no Linux.

#5

É verdade. Tem o problema de estar rodando no Windows, mas o Tomcat, mesmo no Linux, às vezes se perde.

[]´s

#6

André, realmente eu digo deploy para me referenciar ao ato de eu jogar o .war e o tomcat descompactar e fazer o resto.

Então David, eu uso windows para desenvolver (normas da empresa) e notei que quando estou no início do projeto, ou seja, o .war a implantar ainda é pequeno e não tem muitas .jar de dependências, eu cosigo fazer hotdeploy no tomcat rodando no windows normalmente. Quando o projeto vai ficando maior, no caso esse que estou com problemas agora está com 10MB, aí começa a ocorrer o problema. No linux o problema não é tão frequente, mas ocorre também. Por exemplo, implantando esse projeto que descrevi no primeiro post, no windows não dá certo nunca. No linux o hotdeploy é bem sucedido 1 vez a cada 2.

Eu sempre achei que fosse uma dependência que eu tenho ou alguma funcionalidade do tomcat que eu passo a usar e daí causa o problema.
Pelo que a galera está dizendo o problema é geral.

#7

Maruero,

Pois é, o problema não é só com você não. Tentei em casa e não deu certo com um war de 3mb já. Devo ter feito alguma coisa errada.

De qualquer forma, hotdeploy, na minha opinião, é algo delicado. Você faz um correção, faz o hotdeploy e, se não funcionar (sendo erro do desenvolvedor ou problema do hotdeploy), o ideal é sempre parar o servidor e tenta subir novamente (você mesmo deve saber disso). Só ocorrem exceções com arquivos que são, digamos, ‘recursos’, como arquivos jasper ou xml.

Aliás, não que seja do meu interesse, mas 10 mega é algo grande né? Não teria como jogar alguns jars dentro da pasta lib do Tomcat? No JBoss é comum isso… O ear com algumas libs que sofreram mudanças (essas vão pra lib), mas o resto das libs, como as estáticas (leia-se third party, as quais atualizamos somente quando precisamos de alguma nova funcionalidade ou a performance foi melhorada pelos desenvolvedores), deixamos sempre na pasta lib. Mas como eu disse: isso não é do meu interesse né… Só estou sendo inxerido hehe.

Abraço.

#8

Tente adicionar ao elemento o atributo antiJARLocking=“true”

#9