Depois de configurar o Log4j2 como descrevi aqui estava tudo funcionando da forma como queria, só tinha um porém, os logs do Hibernate 4 não apareciam, na console aparecia a query e nada mais.
Depois de fazer uma longa pesquisa no oráculo nosso de cada dia (leia-se google) encontrei diversas pessoas com o mesmo problema, só que não existe uma solução que atenda a todos, por isso vou contar um pouco de história e explicar como eu consegui resolver esse problema, let’s go.
Um pouco de história…
Vou começar explicando por que considero essa parte importante, o contexto e o background do problema podem ajudar a outras pessoas que possuem um cenário diferente do meu e dessa forma adaptar ao seu cenário.
Pra começo de conversa desde a versão 4 o Hibernate utiliza o Jboss Logging como fachada para implementação de logs, anteriormente era utilizada o Slf4j, é esse o nosso ponto de partida. Até a última versão do Hibernate (4.3.9.Final no momento em que escrevo esse texto) a dependência do JBoss Logging é a 3.1.3.GA e a mesma não possui suporte para Log4j2.
Buscando ser compatível com o Log4j2 o time do Jboss Logging resolveu implementar essa compatibilidade na versão 3.2.0.Beta1 que foi baseada, adivinhem em qual versão do Log4j2?!? em uma versão também beta do Log4j2. Só que o time do Log4j2 mudou a API e quebrou a compatibilidade da versão 3.2.0.Beta1, somente a partir da versão 3.2.1.Beta2 do Jboss Logging é que de fato a integração com o Log4j2 funciona a contento.
Solução
A solução para usar o Hibernate 4 com o Log4j2 é sobrescrever a dependência do Jboss Logging, substituindo a versão 3.1.3.GA com a versão 3.2.1.Beta2 ou superior. No momento que escrevo esse post a última versão é 3.2.1.Final e foi ela que usei. Para quem usa maven basta adicionar a dependência no pom.xml da seguinte forma:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.2.1.Final</version>
</dependency>
Feito isso o nosso Hibernate 4 vai funcionar corretamente. Mas dependendo do cenário pode ser que seja necessário realizar outros ajustes, como no meu caso…
Meu cenário
Uma aplicação web rodando no Glassfish 4.1, neste caso o Glassfish utiliza uma implementação do Jboss Logging que é 3.1.3.GA que fica dentro do diretório modules do Glassfish. Dessa forma ao fazer o deploy ele carrega a versão 3.1.3.GA antes de carregar os jar que estão dentro do WEB-INF/lib da minha aplicação, dentre esses jars esta a versão atualizada do Jboss Logging 😦
Moral da história a versão atualizada não é utilizada, atualizar a versão que está dentro do diretório modules seria uma saída, eu disse seria, ao atualizar a versão o Glassfish apresenta um erro. Me parece que esse erro acontece por que existe alguma implementação tentando fazer um import que não existe no jar novo.
A minha solução foi adicionar um atributo no glassfish-web.xml que faz com que ele carregue primeiro as classes que estão dentro do WAR, dessa forma:
<class-loader delegate="false"/>
Ai sim tudo funciona normalmente!!!
O único ponto de atenção que se deve ter é quando esse WAR acessa outros módulos de fora do WAR, por exemplo, módulos de um projeto EAR. Nessa caso a aplicação web não vai funcionar e a única solução é: trocar de servidor ou utilizar a versão antiga do Log4j, a versão 1.2.
Referências:
http://wiki.apache.org/logging/Log4j2AndHibernate4
http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html
https://issues.jboss.org/browse/JBLOGGING-94
Fui.
Coffee Server 