--- title: Dependências e pré requisitos --- #Dependências e pré requisitos O VRaptor 4 depende do JDK 1.7 e do CDI 1.1, portanto só funcionará nos servidores que suportem essa versão do CDI. Os servidores já testados e suportados são: - Glassfish 4 - WildFly 8.0 - Tomcat 7 (+ jars do Weld 2.0) - Jetty 8 e 9 (+ jars do Weld 2.0) 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`: ~~~ #!xml org.jboss.weld.environment.servlet.Listener ~~~ ## 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. ~~~ #!xml br.com.caelum vraptor 4.0.0 ~~~ 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. ### CDI Esta é a dependência mais importante do VRaptor 4. Se você usa um Application Server, ele já possui esta dependência, portanto você pode declarar no seu `pom.xml` como `provided` conforme exemplo: ~~~ #!xml javax.inject javax.inject 1 provided ~~~ E se você utiliza um Servler Container (como o Tomcat ou Jetty) você precisa adicionar a implementação de referência do CDI: o Weld. ~~~ #!xml org.jboss.weld.servlet weld-servlet-core 2.1.2.Final org.jboss.weld weld-core-impl 2.1.2.Final ~~~ **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 (o terrível class loader hell). ## 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: ~~~ #!xml org.slf4j slf4j-log4j12 1.7.5 ~~~ Incluir um arquivo de configuração chamado `log4j.xml` na pasta de `src/main/resources` do projeto, por exemplo: ~~~ #!xml ~~~ ## 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. Para XStream: ~~~ #!xml com.thoughtworks.xstream xstream 1.4.4 ~~~ E para o Gson ~~~ #!xml com.google.code.gson gson 2.2.4 ~~~ ## Bean Validation Necessário para utilizar a funcionalidade de validação. Você precisará adicionar a API `validation-api` e alguma implementação, como por exemplo, o Hibernate Validator ou o Apache BVal. 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. ## Paranamer Infelizmente, o Java não realiza 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. Para adicionar o `commons-fileupload` é necessário adicionar também o `commons-io` no classpath. ~~~ #!xml commons-fileupload commons-fileupload 1.3 ~~~