Vraptor 4.2.0-final - Interceptor não mantém mensagem ao fazer result.redirect()

Tenho uma aplicação em que atualizei para Vraptor4.2.0-final/Tomcat8/Hibernate5.

Tem um interceptor que verifica se há um usuarioSessao (usuário logado/autenticado) e analisa se a lógica em questão. Se a lógica não tem anotação, significa que é necessário que o usuario esteja logado/autenticado E que tenha um usuarioSessao (SessionScoped). OK.

Notei que, se não estou logado no sistema e tento acessar uma rota que precisa estar logado, o Intereceptor é acionado corretamente. Ele verifica que não tem o usuarioSessao corretamente. OK. Faço um include de uma mensagem para ser exibida na view com result.include(“erro”, “É necessário Logar primeiro.”) e em seguida faço um result.redirectTo(LoginController.class).loginForm();
O problema é que essa mensagem nunca chega na view.
Se eu faço o downgrade para o Vraptor 4.1.4, está funcionando corretamente.
Mas só de mudar o pom.xml para usar a versão 4.2.0-final, não funciona mais.
Habilitei o DEGUB no log4j e consigo ver que os includes funcionam corretamente, mas, quando o interceptor é executado novamente após o redirect(), os includes TODOS somem.
Se eu mudo o result.redirectTo para result.use ou result.forwardTo, o fluxo ocorre como esperado, e os includes permanecem. Mas no caso do redirect não. Bastou eu fazer o downgrade para 4.1.4 que funciona, mas o comportamento no 4.2.0-final está dessa forma.
Será que esqueci de configurar algo? Ou eu tenho que implementar alguma classe “extra” ?

Um outro tópico também é que precisei desativar o vraptor-i18n também em 4.2.0-final porque, após passar pelo redirectTo que está nesse interceptor, o sistema adiciona “en-us” em na URL: https://meuapp.tld/en-us/login

Poderiam me ajudar com pelo menos o problema dos results.include que somem ao serem usados com redirectTo no Interceptor?

Parte do código no Interceptor:

@Intercepts
@RequestScoped
public class PermissaoInterceptor{

    @AroundCall
	public void intercept(SimpleInterceptorStack stack) {
		System.out.println("\n\n####### interceptando o método: >>>>>> " + methodInfo.getControllerMethod().getMethod().getName() + "\n\n");
        if (methodInfo.getControllerMethod().containsAnnotation(AcessoPublico.class)){
			result.include("msg", "ok, metodo público, não precisa de usuarioSessao.");
			stack.next();
			return;
		}
        if(usuarioSessao == null){
            result.include("msg","método não tem anotação @AcessoPublico E deveria existir um usuarioSessao, que não foi encontrado. FAZER LOGIN.")
            result.redirecTo(LoginController.class).loginForm();
            return;
        }
        stack.next();
    } 
        

E no controller, lógica que abre o form de login tem a anotação e mais nada:

@AcessoPublico
@Path("/login")
@Get
public void loginForm(){
}

@Path("/login/teste")
@Get
public void teste(){
    result.include("msg", "chamou o método teste!")
}

E a anotação @AcessoPublico está assim:

@Target(value = { ElementType.METHOD })
@Retention(value = RetentionPolicy.RUNTIME)
public @interface AcessoPublico {

}

E seguindo o fluxo, ocorre normalmente; exemplo sem estar logado e tento acessar /login/teste (exige login):
/login/teste → interceptor verifica que não há usuarioSessao, faz o include, faz o redirect → sistema procura e acha a lógica /login → interceptor verifica que a lógica tem a anotação AcessoPublico (NESTE MOMENTO, os result.include anteriores somem todos), faz o stack.next() , return e executa a lógica loginForm() (que não tem nada, apenas abre o JSP correto), mas no JSP, os includes não existem.

Basta apeans eu ir no pom.xml e fazer o downgrade do vraptor4.2.0-final para vraptor4.1.4 que funciona corretamente. Mas no 4.2.0 tem esses 2 probleminhas.

Sinceramente? Fica na versão que funciona… A última versão é de 2017.

É o que fiz, por enquanto… Mas sinceramente, é muito desmotivante. Falta muita, mas muita documentação. E o ruim é que tenho mesmo que usar Vraptor… Até o Laravel está mais “suportável”, tistreza :slight_smile:

O erro é escolher essas bombas. VRaptor nunca pegou, foi só mais uma modinha há anos atrás… Fica na versão que resolve seu problema e empurra enquanto der. Atualizar por atualizar, se não faz realmente alguma diferença do ponto de vista de segurança ou de funcionalidade, é besteira. Por isso q eu detesto tanto a maioria dos frameworks, principalmente os front-end. Não passam de modismos que ficam reinventando a roda milhares de vezes. Eu prefiro ficar sempre no mais cru possível, uma ou outra biblioteca básica e pronto. Os poucos que eu confio em Java são o Hibernate e o Spring.

1 curtida