VRaptor 3 não funciona no Glassfish v3, por causa do Log4J

Assuntos Gerais
#1

Eu tentei criar uma aplicação de teste (estilo aqueles de Blog, comum ao Rails) fazendo deploy num servidor Glassfish v3.

Sei muito bem que Glassfish não usa o Log4J, preferindo o Logging padrão do Java SE. Por isso mesmo, naquele projeto em branco, removi a biblioteca slf4j-log4j12-1.5.6.jar (botando a slf4j-jdk14-1.5.6.jar no lugar) e também removi a log4j-1.2.12.jar. Não deu certo, porque diz que não encontra a classe Logger da log4j.

Pois bem, recoloquei o jar do log4j, e agora dá um erro 500, mas cujas mensagens de erro não aparecem porque não é esse o log que o Glassfish reconhece.

Minha impressão é que, em algum ponto do código, não foi utilizado o SLF4j, preferindo o Log4J diretamente. Mas isso é ruim, já que limita minha opção de escolha.

Depois, fui tentar fazer o deploy num servidor Jetty 6.1.20, onde a mensagem de erro apareceu, pelo menos. Mas não dá pra saber o que fazer:

2009-09-06 18:21:56.509::WARN:  /VRaptorBlog/post/new
java.lang.IllegalStateException: STREAM
	at org.mortbay.jetty.Response.getWriter(Response.java:616)
	at br.com.caelum.vraptor.resource.DefaultResourceNotFoundHandler.couldntFind(DefaultResourceNotFoundHandler.java:52)
	at br.com.caelum.vraptor.interceptor.ResourceLookupInterceptor.intercept(ResourceLookupInterceptor.java:66)
	at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler.execute(ToInstantiateInterceptorHandler.java:57)
	at br.com.caelum.vraptor.core.DefaultInterceptorStack.next(DefaultInterceptorStack.java:71)
	at br.com.caelum.vraptor.core.DefaultRequestExecution.execute(DefaultRequestExecution.java:71)
	at br.com.caelum.vraptor.VRaptor$1.insideRequest(VRaptor.java:99)
	at br.com.caelum.vraptor.ioc.spring.SpringProvider.provideForRequest(SpringProvider.java:38)
	at br.com.caelum.vraptor.VRaptor.doFilter(VRaptor.java:97)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1153)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
	at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.Server.handle(Server.java:326)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:913)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
#2

essa exception acontece por causa de um bug no beta-2 do vraptor (escrever na saida depois de gerar um erro 404)
na versão beta-3 isso foi corrigido… tenta atualizar o jar e ver se funciona

[]'s

#3

[quote=lucascs]essa exception acontece por causa de um bug no beta-2 do vraptor (escrever na saida depois de gerar um erro 404)
na versão beta-3 isso foi corrigido… tenta atualizar o jar e ver se funciona

[]'s[/quote]

Oi Lucas,

eu fiz assim, peguei a última versão de vocês no GitHub, e fui buscar as classes que estavam dependendo do Log4J ao invés do SLF4J, e alterei manualmente. São elas:

br.com.caelum.vraptor.ioc.spring.ComponentScanner.java
br.com.caelum.vraptor.core.JstlLocalization.java

Ai consegui remover a dependência do jar log4j tranquilamente.

O NotFound permaneceu, mas aí conseguir ver que o problema era o Path que estava “errado”. Ao invés de:

@Path("/post/new")

escrevi:

@Path("post/new")

Ou seja, sem a barra inicial. Eu achei isso estranho, não seria interessante o VRaptor ignorar as ausências de barra inicial e acrescentá-las normalmente? Ou pelo menos, exibir mensagens de warning na inicialização?

#4

Olá Leonardo,

não faz sentido mesmo ter classes dependendo direto do log4j… já corrigi no source
mas de qqer forma o slf4j estava usando o log4j por trás, então bastava só tirar o jar do
log4j da aplicação e deixar o do servidor…

e pra próxima versão o vraptor vai dar um warning e colocar a barra no começo da uri se ela não existir,
já tá no source…

Obrigado =)

[]'s

#5

oi leonardo!

valeu as contribuicoes. o lucas ja criou as issues no GIT e ja eliminou no source. tirou as referencias para o log4j e fez o sistema de colocar / automaticamente (mas dando warning).

a release RC1 deve chegar em breve! paramos de ter bugs medianos ha alguns dias.

#6

Leonardo3001, eu uso vraptor no glassfish. Quanto ao log4j o mesmo funciona sim no glassfish. Já fiz testes com o backlog que também funcionou sem problemas.

Qual o problema que você teve com o log4j no glassfish?

#7