Neste fim de semana quis fazer alguns testes pela primeira vez com uma aplicação grails no jboss.

Já tinha acompanhado na grails-users que existem alguns problemas para efetuar o deploy, e para cada um deles, uma sequência de passos obscuros para fazer o deploy acontecer com sucesso. Minha versão de grails neste procedimento é a 1.2.1 e do JBoss é a 5.1.0.GA

Efetivamente, o que acontece é que jboss traz junto com suas common libs vários jars que são empacotados juntamente com a sua aplicação quando você utiliza o comando grails war.

Existem alguns workarounds na internet que te mostram como modificar o BuildConfig.groovy (arquivo que define propriedades do empacotamento de sua app) para que após montar a estrutura de arquivos que irão ser empacotados, remova estes arquivos (principalmente o log4j onde o problema é mais aparente) do chamado stagingDir e os deixe de fora do pacote final.

Particularmente, achei a solução um tanto quanto diferente e acabei achando no FAQ do Grails e depois com mais detalhes nesta página uma solução menos intrusiva ao pacote, que é definir a prioridade de carregamento dos jars da aplicação.

Bom, para isso, precisamos criar um arquivo jboss-web.xml dentro do diretório WEB-INF de nossa aplicação que irá mostrar ao jboss que queremos “blindar” nossa aplicação para utilizar os jars que estão dentro de seu lib, e que estes por sua vez não deverão ser sobrescritos pelos jars do classpath do servidor. O conteúdo do arquivo segue abaixo:

<jboss-web>
   <context-root>/projeto</context-root>
   <class-loading java2ClassLoadingCompliance="false">
      <loader-repository>
         projeto:archive=projeto.war
         <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
      </loader-repository>
   </class-loading>
</jboss-web>

Na tag context-root estamos apenas aproveitando que a aplicação terá seu arquivo de configuração específico para o jboss e definindo o contexto em que ela será publicada. Nas tags seguintes pedimos para o jboss criar o nosso classloader isolado, com o nome “projeto:archive=projeto.war”. Com este nome (que deve ser único, por isto leva em consideração o nome do projeto), garantimos que as classes pedidas pelo nosso projeto serão procuradas ali, e caso não encontradas, nos classpaths seguintes (common/lib, depois no tomcat).

Basicamente isto seria suficiente para conseguir que o projeto rodasse sem problemas. Porém no meu cenário de versões (grails 1.2.1 e jboss-5.1.0.GA) existe outro ponto de conflito. O Hibernate Validator que está junto ao jboss também difere em versão e gera conflito com o grails. Neste caso a solução é ainda mais interessante e simples que a anterior.

Para resolver o problema no deploy que indica claramente problema de versão no Hibernate Validator, basta que você faça o download da última versão deste jar (no meu caso, 4.0.2-GA) nesta url: https://www.hibernate.org/30.html. Depois disto, resta apenas colocar o jar do hibernate validator dentro da pasta <jboss_home>/common/lib.

Pronto, a aplicação está rodando e funcional dentro do jboss!

10:36:32,815 INFO  [[/projeto]] Initializing Spring root WebApplicationContext
10:36:41,155 INFO  [[/projeto]] Initializing Spring FrameworkServlet 'grails'

PS: Vale lembrar que o arquivo jboss-web.xml é padrão para arquivos war, se você quiser configurar a ordem do classpath para aplicações ear ou sar, consulte o link acima para entender as diferenças.