Estou tentando configurar a aplicação pra, ao acontecer algum erro (exceção, 404, 500, etc), o usuário ser direcionado pra home.
O problema é que eu preciso executar um pré processamento antes de exibir a página. Pra isso eu tentei configurar assim o web.xml:
<error-page>
<location>/</location>
</error-page>
Ou seja, ao acontecer algum erro, o usuário deve ser direcionado pra www.meusite.com.br/
Mas isso não tá funcionando. Quando eu tento acessar uma página inválida ou forço acontecer uma exceção aparece a mensagem de erro do navegador:
[quote=Lucas Cavalcanti]dá alguma exception no console do servidor?
se isso vai passar pelo VRaptor vc precisa acrescentar o dispatcher de ERROR nele.[/quote]
Dessa forma que eu fiz não lançava exception não. Mas quando eu adicionei o dispatcher de ERROR no VRaptor, passou a lançar uma NullPointerException:
SEVERE: Exception Processing ErrorPage[errorCode=0, location=/]
java.lang.NullPointerException
Eu não sei se eu configurei certo o dispatcher. Fiz assim:
[code]SEVERE: Servlet.service() for servlet default threw exception
java.lang.NullPointerException
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:321)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at br.com.caelum.vraptor.resource.DefaultResourceNotFoundHandler.couldntFind(DefaultResourceNotFoundHandler.java:41)
at br.com.caelum.vraptor.interceptor.ResourceLookupInterceptor.intercept(ResourceLookupInterceptor.java:71)
at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler.execute(ToInstantiateInterceptorHandler.java:54)
at br.com.caelum.vraptor.core.DefaultInterceptorStack.next(DefaultInterceptorStack.java:54)
at br.com.caelum.vraptor.core.EnhancedRequestExecution.execute(EnhancedRequestExecution.java:44)
at br.com.caelum.vraptor.VRaptor$1.insideRequest(VRaptor.java:91)
at br.com.caelum.vraptor.ioc.spring.SpringProvider.provideForRequest(SpringProvider.java:58)
at br.com.caelum.vraptor.VRaptor.doFilter(VRaptor.java:88)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:489)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:456)
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:327)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:193)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Abr 02, 2013 11:04:32 AM org.apache.catalina.core.StandardHostValve custom
SEVERE: Exception Processing ErrorPage[errorCode=0, location=/]
java.lang.NullPointerException
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:321)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at br.com.caelum.vraptor.resource.DefaultResourceNotFoundHandler.couldntFind(DefaultResourceNotFoundHandler.java:41)
at br.com.caelum.vraptor.interceptor.ResourceLookupInterceptor.intercept(ResourceLookupInterceptor.java:71)
at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler.execute(ToInstantiateInterceptorHandler.java:54)
at br.com.caelum.vraptor.core.DefaultInterceptorStack.next(DefaultInterceptorStack.java:54)
at br.com.caelum.vraptor.core.EnhancedRequestExecution.execute(EnhancedRequestExecution.java:44)
at br.com.caelum.vraptor.VRaptor$1.insideRequest(VRaptor.java:91)
at br.com.caelum.vraptor.ioc.spring.SpringProvider.provideForRequest(SpringProvider.java:58)
at br.com.caelum.vraptor.VRaptor.doFilter(VRaptor.java:88)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:489)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:456)
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:327)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:193)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)[/code]
private final Result result;
public IndexController(Result result) {
this.result = result;
}
@Path(value = "/")
public void index(Integer logo, Integer topo) {
if (logo == null) {
logo = 1;
}
if (topo == null) {
topo = 1;
}
result.include("logo", logo);
result.include("topo", topo);
}
}[/code]
Inclusive, quando eu acesso a url “/”, funciona…
Esse resource not found não pode ser da url de erro que eu to testando? Pra testar o mapeamento de erro padrão, eu to tentando acessar uma url inválida, “localhost:8080/url-invalida” por exemplo. Essa URL que não tem controller. Mas minha intenção é tratar esses casos através no mapeamento de erro, direcionando pro controller que responde por “/”.
em todo caso, algum motivo especial para não ter uma página dedicada de erro 500?[/quote]
Tem sim. É que eu to trabalhando com Scrum. Scrum é uma metodologia ágil que separa o desenvolvimento em ciclos de tempo definido. Em cada ciclo, só é implementado o que foi combinado previamente, pra dar tempo de ter, no final desse ciclo, um produto 100% funcional. Enfim, a página dedicada de erro não tá prevista no ciclo atual de desenvolvimento.
Além disso, eu queria direcionar qualquer erro pra página inicial, porque lá tem um Google Analytics onde eu posso rastrear se a pessoa tentou acessar alguma página inválida. Isso ajudaria muito a priorizar as tarefas dos próximos ciclos de desenvolvimento. A grosso modo, funcionaria mais ou menos dessa forma:
Muita gente acessando páginas inválidas: vamos fazer uma página de erro dedicada com uma ferramenta de busca e principais links do site.
Um número médio de pessoas estão caindo em URL’s inválidas: vamos fazer só uma página de erro simples só com principais links.
Se quase ninguém tá caindo em URL’s inválidas: vamos deixar essa demanda pro futuro e nos preocupar com o que é mais prioritário no momento.
O nome disso é “desenvolvimento orientado a métricas”
Você teria mais alguma sugestão?
PS: muito obrigado pela ajuda. Você parece ser a única pessoa que entende de VRaptor! E dá pra ver que entende bem
[quote=Lucas Cavalcanti]Pensando em experiência do usuário é bem ruim tentar fazer alguma ação e ser enviado para a página inicial.
Você deve gastar só 10 min pra escrever uma página 500 básica falando que deu um erro e colocando um link pra home.
O desenvolvimento orientado a métricas deve ser usado pra funcionalidades que vão exigir um certo esforço, o que não é o caso.
Aposto que vc gastou mais tempo escrevendo nesse tópico do que vc gastaria escrevendo um html estático de erro 500
Em todo caso, isso não esconde o fato de que isso é um bug do VRaptor, mas fica a dica.[/quote]
Você tem razão. Mas a questão é que nós nunca tínhamos trabalhado com o VRaptor, não dava pra saber qual seria o esforço de fazer uma página de erro. Tem que levar em conta o tempo de aprendizado. Esse projeto tá andando em marcha lenta ainda por conta disso, hehe.
Mas agora que eu já sei que se direcionar pro jsp funciona, é isso que eu vou fazer
De qualquer forma, minha curiosidade permanece: isso que aconteceu é um bug mesmo do VRaptor? Você tentou/conseguiu reproduzir o erro?
E só mais uma curiosidade: você trabalha na Caelum? Mantém o VRaptor?
Teve uma coisa que eu esqueci de relatar. Esse mapeamento de error-page (sem especificar código de erro para o qual eu pretendo tratar) só funciona em servlet 3.0. Mas o projeto padrão do VRaptor vem com o cabeçalho do web.xml como se fosse servlet 2.5. Ou seja, pra fazer funcionar esse mapeamento de erro genérico, eu tive que mudar o cabeçalho do arquivo. O VRaptor funciona em cima do servlet 3.0, certo?
Não sei se é um bug do VRaptor ou é porque o VRaptor é um filtro e filtros não funcionam bem com páginas de erro. Não tive tempo de tentar reproduzir ainda.
Não trabalho mais na Caelum, mas ainda mantenho o VRaptor sim.
[quote=Lucas Cavalcanti][quote=gutomarzagao]
De qualquer forma, minha curiosidade permanece: isso que aconteceu é um bug mesmo do VRaptor? Você tentou/conseguiu reproduzir o erro?
E só mais uma curiosidade: você trabalha na Caelum? Mantém o VRaptor?
[/quote]
Não sei se é um bug do VRaptor ou é porque o VRaptor é um filtro e filtros não funcionam bem com páginas de erro. Não tive tempo de tentar reproduzir ainda.
Não trabalho mais na Caelum, mas ainda mantenho o VRaptor sim.[/quote]
Parabéns pelo trabalho de vocês. Até agora, um dos melhores frameworks web que eu já vi…
A documentação que poderia melhorar. Não dá pra conhecer o framework a fundo com o que tem no site…