VRaptor

Dependências e pré-requisitos

O VRaptor 4 depende diretamente do CDI versão 1.1, portanto só funcionará nos servidores que suportem essa versão do CDI ou superior como CDI 1.2. Também é necessário possuir JDK 1.7 ou superior. Se for usar Java 8, não deixe de conferir este tópico.

Os Servidores de Aplicações já testados e suportados são:

E os Servlet Containers suportados são:

Ao usar um Servlet Container como o Tomcat ou Jetty, é preciso adicionar os jars do Weld 2.x, além do seguinte listener em seu web.xml, para que seja possível ativar o CDI:

<listener>
    <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
</listener>

E o arquivo beans.xml, que é opcional se você estiver usando um Application Server, que deve estar dentro do WEB-INF de sua aplicação:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
    version="1.1" bean-discovery-mode="all">
</beans>

Algumas dependências podem variar se você usa um Application Server ou um Servlet Container. Pacotes da especificação, como o CDI ou Bean Validation, não são necessários quando você usa um Application Server.

JDK 8

É possível usar JDK 8 com o VRaptor. Porém é importante atualizar a dependência do Javassist para a última versão, pois as anteriores ainda não possuem suporte ao bytecode gerado pelo Java 8.

<dependency>
    <groupId>org.javassist</groupId>
    <artifactId>javassist</artifactId>
    <version>3.18.1-GA</version>
</dependency>

Nota: Se você usa Wildfly, tente usar a versão 8.1, pois o Javassist já é disponibilizado nos módulos do servidor. Sendo assim mesmo que você defina a dependência na aplicação, ela será ignorada. Uma alternativa, se você não pode usar a versão 8.1, é atualizar o módulo direto no servidor.

Você pode precisar também adicionar o plugin VRaptor Java 8 ao seu projeto.

Maven

O VRaptor 4 usa como padrão o Maven para gerenciar as dependências. Com isso basta você adicionar o artefato do vraptor como dependência, e o Maven irá se encarregar de fazer o download de todas as dependências obrigatórias.

<dependency>
    <groupId>br.com.caelum</groupId>
    <artifactId>vraptor</artifactId>
    <version>4.2.0-RC5</version>
</dependency>

A estrutura do projeto baseado no Maven é um pouco diferente da estrutura convencional usada pelas IDEs. No entanto quando o projeto é empacotado, o Maven irá gerar a estrutura padrão de um WAR.

Local Maven Descrição Local no pacote WAR
src/main/java fontes Java /WEB-INF/classes
src/main/resources arquivos de configuração /WEB-INF/classes
src/main/webapp arquivos web /
src/test/java fontes Java para testes - ignorado -
src/test/resources arquivos de config. para testes - ignorado -

Se você não quiser usar o Maven, basta criar um projeto em branco na sua IDE preferida e adicionar o jar do VRaptor com as dependências. Todos os jars necessários para usar o VRaptor estão disponibilizados no zip em nossa página de downloads.

CDI

Esta é a dependência mais importante do VRaptor 4. Se você usa um servidor de aplicação, que já possui essa dependência, você não precisará declará-la novamente em seu pom.xml.

Caso você utilize um Servlet Container (como o Tomcat ou Jetty), você precisará adicionar a implementação de referência do CDI: o Weld.

<dependency>
    <groupId>org.jboss.weld.servlet</groupId>
    <artifactId>weld-servlet-core</artifactId>
    <version>2.1.2.Final</version>
</dependency>

<dependency>
    <groupId>org.jboss.weld</groupId>
    <artifactId>weld-core-impl</artifactId>
    <version>2.1.2.Final</version>
</dependency>

Observação importante: evite usar o artefato org.jboss.weld.servlet:weld-servlet. Este artefato contém todas as classes necessárias, porém contém mais classes do que é preciso para subir a sua aplicação. Em particular, o weld-servlet contém uma cópia de todo o código do guava, que já é dependência do VRaptor, o que pode gerar conflitos entre as classes dos dois artefatos.

Logging

Utilizamos o SLF4J (Simple Logging Facade for Java) para imprimir os logs dos eventos internos. SLF4J pode direcionar o logging para vários frameworks de logging como NOP, Simple, log4j e JDK Logging. Para configurar o logging você precisa adicionar no seu classpath o jar slf4j-api.jar juntamente com o jar de binding que você escolher. Veja mais sobre o assunto na documentação do SLF4J.

A maioria dos projetos preferem usar o log4j como implementação de logging. Caso você queira usá-lo, basta adicionar nas dependências do projeto o seguinte artefato:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.5</version> <!-- ou a última versão disponível -->
</dependency>

E inclua um arquivo de configuração chamado log4j.xml na pasta de src/main/resources do projeto, por exemplo:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
    <appender name="stdout" class="org.apache.log4j.ConsoleAppender">
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d{HH:mm:ss,SSS} %5p [%-20c{1}] %m%n" />
        </layout>
    </appender>
    <category name="br.com.caelum.vraptor">
        <priority value="DEBUG" />
        <appender-ref ref="stdout" />
    </category>
    <!-- incluir outras definições aqui -->
</log4j:configuration>

Nota: Se você está fazendo deploy de sua aplicação no Wildfly, você precisará configurar o logging no arquivo standalone.xml (ou no domain.xml se você estiver executando em modo domain):

<subsystem xmlns="urn:jboss:domain:logging:2.0">
    <logger category="br.com.caelum.vraptor">
        <level name="DEBUG"/>
    </logger>
    <!-- restante do conteúdo -->
</subsystem>

Porém se você preferir usar as configurações dentro de sua aplicação usando exemplo de log4j.xml acima, você pode indicar ao Wildfly para que ele considere a configuração na aplicação:

<subsystem xmlns="urn:jboss:domain:logging:2.0">
    <use-deployment-logging-config value="false"/>
    <!-- restante do conteúdo -->
</subsystem>

XStream e Gson

São utililizadas para serialização e deserialização XML e JSON respectivamente. Ambas são opcionais, ou seja, se você não usar os recursos de serialização e deserialização, você pode removê-los do classpath. Atualmente elas já vêm com a dependência do VRaptor no Maven e você não precisa declarar as dependências.

Para XStream:

<dependency>
    <groupId>com.thoughtworks.xstream</groupId>
    <artifactId>xstream</artifactId>
    <version>1.4.4</version>
</dependency>

E para o Gson

<dependency>
    <groupId>com.google.code.gson</groupId>
    <artifactId>gson</artifactId>
    <version>2.2.4</version>
</dependency>

Bean Validation

Se você usa um servidor de aplicações não é necessário adicionar a dependência do Bean Validation, pois já está incluído no Java EE 7. Porém se você usar apenas um servlet container, é necessário adicionar alguma implementação, como o Hibernate validator, em seu projeto incluindo o artefato:

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator-cdi</artifactId>
    <version>5.1.1.Final</version>
</dependency>

Esta dependência é obrigatória pois o VRaptor utiliza os recursos de validação do bean validation em sua classe Validator.

É necessário também indicar ao CDI para não validar os métodos automaticamente. Para isso adicione o arquivo META-INF/validation.xml com o segunte conteúdo:

<?xml version="1.0" encoding="UTF-8"?>
<validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration
        validation-configuration-1.1.xsd"
        version="1.1">
    <executable-validation enabled="false"/>
</validation-config>

Paranamer

Infelizmente, nas versões anteriores ao Java 8, não é possível fazer reflection de parâmetros em métodos e construtores, pois esses dados não ficam disponíveis em bytecode (a não ser se compilado em debug mode, porém é algo opcional). Isso faz com que a maioria dos frameworks que precisem desse tipo de informação criem uma anotação própria para isso, o que polui muito o código (exemplo no JAX-WS, onde é comum encontrar um método como o acima com a assinatura void add(@WebParam(name="cliente") Cliente cliente).

O VRaptor tira proveito do framework Paranamer, que consegue tirar essa informação por meio da pré compilação ou dos dados de debug, evitando criar mais uma anotação. Alguns dos desenvolvedores do VRaptor também participam no desenvolvimento do Paranamer.

Commons-fileupload

Dependência opcional utilizada apenas se sua aplicação possui funcionalidade de upload de arquivos. Se você não usa o Maven, será necessário adicionar também a biblioteca commons-io no classpath.

<dependency>
    <groupId>commons-fileupload</groupId>
    <artifactId>commons-fileupload</artifactId>
    <version>1.3</version>
</dependency>

Iogi

O Iogi é uma biblioteca usada internamente pelo VRaptor para injeção de parâmetros da requisição. A grande vantagem do Iogi é permitir que seus beans possam ser imutáveis, ou seja, instanciados apenas pelo construtor. Ou da forma usual, por meio de setters and getters.

Iogi é uma dependência obrigatória e já vem incluída por padrão se você usa Maven.

Mirror

A biblioteca Mirror permite instanciar beans via Reflection usando uma interface fluente. É usada internamente para instanciar os objetos.

Mirror é uma dependência obrigatória e já vem incluída por padrão se você usa Maven.