VRaptor 4 + Jetty 8

[Benedito Barbosa]

Gostaria de entender porque o VRaptor 4 não localiza as dependências deste projeto: https://github.com/benedito/exemplo.git

Utilizei o Jetty 8.1.17.v20150415 como servlet container. O log gerado está em anexo.

Por meio do Eclipse, gerei o arquivo exemplo.war, que foi copiado para a pasta /webapps do Jetty.

Em seguida, executei o Jetty pelo comando: java -jar start.jar

Mesmo alterando as versões do VRaptor, visualizo o mesmo log.

[Chico Sokol]

Se não me engano precisa habilitar um módulo do jetty para o CDI funcionar. Dá uma olhada na doc do jetty: http://www.eclipse.org/jetty/documentation/9.1.1.v20140108/framework-weld.html

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para caelum-...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/caelum-vraptor.
Para mais opções, acesse https://groups.google.com/d/optout.

[Benedito Barbosa]

Desculpe pela demora. Só agora pude ver a postagem. Realmente, faltava habilitar o modulo CDI no Jetty. No entanto, me deparei com outra exceção (em anexo). Vi no GUJ que poderia ser conflito entre versões do Guava, mas olhando a árvore de dependências (também em anexo) só existe uma biblioteca do Guava e está na versão 15.0.

[Chico Sokol]

Hum... Já tivesse esse problema antes. Um dos jars da do weld tinha uma cópia completa de uma versão do guava (sem nem mudar os pacotes). Consegue ver se a classe com.google.common.collect.FluentIterable está definida em mais de um jar?

[Benedito Barbosa]

Depois de olhar todos os jars, descobri que o Guava é dependência do vraptor (na versão 15.0), do iogi (na versão 11.0.2) e do weld-core-impl (sem versão específica). Então, resolvi excluir de todos e declará-lo na versão 15.0 (conforme abaixo). No entanto, o problema persiste.

<dependency>

<groupId>br.com.caelum</groupId>

<artifactId>vraptor</artifactId>

<version>4.1.4</version>

<exclusions>

<exclusion>

<groupId>com.google.guava</groupId>

<artifactId>guava</artifactId>

</exclusion>

</exclusions>

</dependency>

<dependency>

<groupId>br.com.caelum</groupId>

<artifactId>iogi</artifactId>

<version>1.0.0</version>

<exclusions>

<exclusion>

<groupId>com.google.guava</groupId>

<artifactId>guava</artifactId>

</exclusion>

</exclusions>

</dependency>

<dependency>

<groupId>org.jboss.weld</groupId>

<artifactId>weld-core-impl</artifactId>

<version>2.1.2.Final</version>

<exclusions>

<exclusion>

<groupId>com.google.guava</groupId>

<artifactId>guava</artifactId>

</exclusion>

</exclusions>

</dependency>

<dependency>

<groupId>com.google.guava</groupId>

<artifactId>guava</artifactId>

<version>15.0</version>

</dependency>

[Chico Sokol]

Estranho, consegue ver se a classe FluentIterable tem o método toSet no seu projeto?

[Benedito Barbosa]

Pior que tem!

Já apelei pra sequencia: mvn eclipse:clean + mvn eclipse:eclipse -Dwtpversion=2.0 + mvn package

A exceção continua e ainda não identifiquei o que está faltando pra funcionar.

[Chico Sokol]

:-/

Bizarro. E se você gerar o war na mão e subir o jetty na linha de comando com esse war?

Uma observação para todos: já tivemos vários problemas com o guava (em geral por culpa de outras libs que usam o guava tbm). Será que não seria uma boa remove essa dependência do VRaptor? O guava ajuda bastante mas não deveria ser uma dependência essencial do VRaptor...

[Rodrigo Turini]

Eu lembro que fiz um teste tirando o guava do vraptor, pra sair migrando os códigos. Foi um pesadelo. Nós usamos muito, e em alguns lugares, o código fica bem melhor mesmo (com java 8 já não é verdade). Mas o pior mesmo é que tirar não vai resolver 100% o problema, j;a que o IOGI e outras dependencias tb usam guava, né? Por isso desisti na epoca e acho que não vale tanto a pena mudar agora.

Benedito, sobre o seu problema, se você tirar a dependência do guava que você adicionou manualmente e mandar o maven resolver as dependências, não vai ter nenhum guava mesmo? (só pra confirmar se não tem mais ninguém além desses que você deu exclude). Outra coisa, você já tentou usar outra versão do guava?

[Valério]

Por aqui uso um projetinho util para criar métodos utilitários (alguns na mão) e outros delegando pro apache commons (envio de e-mail e uns I/Os mais malignos); podia ser pro guava. Fato é que com esse façade o resto das aplicações se acopla nas classes que delegam (minhas classes) e não nas bibliotecas externas. Se amanhã eu trocar o commons pelo guava ou qualquer outra coisa o impacto vai ser só nesse projetinho.

Att,

Valério

[Benedito Barbosa]

Eu realmente não sei o que pode está errado. Fiz várias tentativas com vários cenários diferentes. Hoje, a aplicação de exemplo sobe sem problemas, mas ao chamar qualquer método do controller essa exceção é lançada. Já conferi e todas as bibliotecas estão presentes na pasta lib do war. Resolvi continuar meus estudos do VRaptor 4 com o Tomcat.