quinta-feira, 15 de dezembro de 2011

Tomcat segundo round! 32 x 64, quem ganha!


Nas lutas que temos que enfrentar nesse mundo, acho que a pergunta não seria qual ganha 32 ou 64bits, mas sim, por quanto tempo você fica em pé após brigar com esses dois sujeitos. No meu caso, máquina rodando com 64bits e intalação do Tomcat + Java rodando com 32 bits, e adivinha! troca de golpes, alguns cruzados, um em cheio de direita e tive que recorrer ao treinador, toalha branca e enfim, lona!!   Fiquei na lona por mais de 8 segundos! e se não fosse com a ajuda dos universitários, meu filho, estaria numa enrascada até agora.

Uma das coisas interessantes nessa disputa é que o Genexus vem se esforçando para tornar a sopa menos salgada, automatizando ao máximo o processo para que não tenhamos que perder tanto tempo assim.  Mas quando falamos que temos que mesclar uma série de tecnologias distintas, a coisa, infelizmente, não fica apenas com o Genexus.

Tomcat e Java 32 Bits
Acho que o erro começou ai, mas fazer o que, tinha o Tomcat e Java 64 Bits e não conseguia fazer funcionar de jeito nenhum, então, em uma tentativa desesperada desinstalei os dois marmanjos e optei por versões não tão atuais de 32 bits, que segundo as boas linguas, eram mais estáveis. Estou falando do Tomcat 6.0.18 e do Java 1.6. 0_25, ambos de 32 bits.

E na esperança de que tudo se resolveria facilmente com versões mais estáveis parti para uma nova kb, as infelizmente nada funcionou direito.

Recebia uma sonora e insistente mensagem HTTP Status 500


type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception

javax.servlet.ServletException: java.lang.NullPointerException at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.
java:169) at com.genexus.webpanels.GXWebObjectStub.callExecute(GXWebObjectStub.java:47) at com.genexus.webpanels.GXWebObjectStub.doGet(GXWebObjectStub.java:27) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:402) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:134) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:857) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509) at java.lang.Thread.run(Thread.java:662) com.genexus.webpanels.GXWebObjectStub.callExecute(GXWebObjectStub.java:99) com.genexus.webpanels.GXWebObjectStub.doGet(GXWebObjectStub.java:27) javax.servlet.http.HttpServlet.service(HttpServlet.java:617) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:402) org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:134) javax.servlet.http.HttpServlet.service(HttpServlet.java:617) javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

note The full stack trace of the root cause is available in the Apache Tomcat/6.0.18 logs.



Apache Tomcat/6.0.18



Dicas para um final Feliz

Como não quero que voce apanhe, vou te dar algumas dicas.

1) Use o Genexus para realizar o deploy, não faça nada manualmente.

Aplique o valor Default nas propriedades Servlet e Static content directory na KB, e observe se o valor apresentado corresponde ao diretório de instalação do Tomcat.

No meu caso o valor default apontava para C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\ProjetoTreinamento2JavaMysql\WEB-INF\classes, enquanto que a instalação do Tomcat estava em C:\Program Files (x86)\Apache Software Foundation\Tomcat 6.0\webapps\ProjetoTreinamento2JavaMysql\WEB-INF\classes.  Consegue ver alguma diferença?

Pois é o Default do Genexus não era o mesmo diretório de instalação do Tomcat, por que? o registro do Windows pode não está correto. Solução: corrija no REGEDIT.  Procurando pelas ocorrências de Tomcat e modificando os valores quando necessário.


No meu caso, não apenas o local mas a versão do Tomcat também não era equivalente à instalada.

2) Veja a instalação do Webapps do Tomcat apresenta todos os diretórios (gxmetadata, Metadata, classes DLL na raiz), enfim algo semelhante a:
Caso não estejam na instalação, então, o Gx não está conseguindo realizar o deploy corretamente, provavelmente devido ao problema detectado no item (1).

3) Siga o mecanismo tradicional de instalação de aplicações, caso tenha que recorrer a esse procedimento manualmente.

a) No diretório META-INF crie um arquivo chamado context.xml com o seguinte conteúdo

b) No diretório WEB-INF crie um arquivo chamado web.xml com o seguinte conteúdo.


E não fique nervoso se o Genexus alterar o conteúdo desse arquivo após o deploy, pois é exatamente o que ele vai fazer.

c) No diretório (tomcat)->Catalina->Localhost crie um arquivo com o mesmo nome da aplicação e extensão XML, com o seguinte conteudo:


d) No diretório (tomcat)->Work->Catalina->Localhost crie uma pasta com o mesmo nome da aplicação.

e) Não coloque a mão no Conf->web.xml, mudando o invoker e as outras dicas de posts anteriores.




A última dica é tenha o melhor treinador te ajudando e ai eu incluo o Alex Melo e o Pablo Mazzilli, da Artech, pois quem iria imaginar que na verdade o problema era no Tomcat e não no Genexus!!!!   Enfim, após essa perfeita esfolada acredito que a culpa nem era da compatibilidade com 64 bits e coisa e tal,  faltava apenas estudar o adversário, no REGEDIT!