VRaptor 3 - README.TXT similar ao do Spring

Os jars que estão no WEB-INF/lib do blank project são o mínimo que você precisa pra executar
uma lógica simples no vraptor, mesmo…
Quais bibliotecas você acha que não seriam necessárias?

Dei um olhada na versão beta-1, tavam faltando alguns jars, como o google-collect-snapshot-20080820.jar e o reflections-0.9.2.jar.

Achei bem legal alguns pontos como o suporte fácil a rest…

Vi no vídeo da palestra do falando em java que o guilherme diz que o provider padrão do vraptor 3 é o spring, mas o blank-project vem com o pico… e não consegui fazer ele utilizar o spring…

Alguma dica?

esses jars já estão no blank-project do beta-2…

o beta-2 também tá com o spring por padrão…

se a sua versão ainda estiver usando o pico, basta colocar no seu web.xml:

<context-param>
        <param-name>br.com.caelum.vraptor.provider</param-name>
        <param-value>br.com.caelum.vraptor.ioc.spring.SpringProvider</param-value>
    </context-param>

    <context-param>
        <param-name>br.com.caelum.vraptor.spring.packages</param-name>
        <param-value>br.com.pacote.do.seu.projeto</param-value>
    </context-param>

Baixei o beta2, mesmo assim ele ainda parece estar usando o pico… habilitei o mode debug do log, e aparece ele iniciando o pico-container…

<context-param> <param-name>br.com.caelum.vraptor.spring.packages</param-name> <param-value>br.com.pacote.do.seu.projeto</param-value> </context-param>

esse pacote do meu projeto, pode ser qq pacote raiz, e dai ele faz autodiscover, como um br.com.meusistema.*, ou tem que ser um pacote especifico?

se for um pacote especifico, o spring só vai gerenciar os beans desse pacote?

@wariows
br.com.pacote.do.seu.projeto tem que ser um pacote, ou um conjunto de pacotes separados por vírgula
da onde estão os seus beans marcados com o @Component ou @Resource do vraptor…
pode ser a raiz do projeto, ele procura nos subpacotes também

@luiz_ross
apesar do container geralmente disponibilizar o jstl.jar e o standard.jar, na maioria das vezes você precisa
deles importados no classpath pra poder desenvolver…
quanto ao commons-upload, acho que dá pra gente tentar marcar pra deixar esta dependência opcional sim…
vou colocar nas issues do vraptor

obrigado =)

lucascs:

@wariows
br.com.pacote.do.seu.projeto tem que ser um pacote, ou um conjunto de pacotes separados por vírgula
da onde estão os seus beans marcados com o @Component ou @Resource do vraptor…
pode ser a raiz do projeto, ele procura nos subpacotes também

Não tem uma convenção pra isso?

é meio dificil estabelecer uma convenção para o pacote raiz do seu projeto…
pode ser br.com.qualquercoisa
net.qqercoisa
com.qqercoisa
org.qqercoisa

a gente não pode simplesmente colocar nada, pq o spring vai querer escanear até as
classes que estão dentro dos jars do seu projeto… e isso não é muito bom…

você tem alguma idéia que facilitaria essa configuração inicial?

lucascs:

é meio dificil estabelecer uma convenção para o pacote raiz do seu projeto…
pode ser br.com.qualquercoisa
net.qqercoisa
com.qqercoisa
org.qqercoisa

a gente não pode simplesmente colocar nada, pq o spring vai querer escanear até as
classes que estão dentro dos jars do seu projeto… e isso não é muito bom…

você tem alguma idéia que facilitaria essa configuração inicial?

Ah verdade, agora que caiu a ficha como funciona o provider, eu não vou ter mais o applicationContext.xml…
De fato é dificil pensar numa convenção pra isso…

Vejo que com o pico isso não é necessário, como o pico procura?

com o pico o vraptor escaneia na mão todas as classes que estão na pasta WEB-INF/classes… que geralmente é onde estão as
classes do seu projeto… o spring já faz isso pra você

o vraptor ainda não aproveita o spring se você já está com ele configurado na aplicação, mas isso com certeza
vai ser implementado em um novo release

Alguma documentação para testes unitários já foi feita?

para os testes unitários dos seus controllers?

por causa da interface fluente do Result e do Validator, fica meio difícil testar com eles mesmo…

a gente vai deixar uma implementação disponível do Result e do Validator para testes junto com o vraptor,
mas por enquanto, é só você passar uma implementação falsa…

dá uma olhada no que a gente fez no Calopsita, que usa o vraptor:

colocando essas 4 classes no seu projeto, (se você tiver usando o JMock), o result e o validator não te atrapalham mais…
qualquer coisa é só modificar o código e usar =)

[]'s

E a integração com JPA como ficou? No vRaptor2 tinha 2 opções, ou eu usava o plugin de jpa, ou eu podia fazer o spring gerenciar o entityManager no applicationContext.xml. Agora que não tenho mais esse arquivo, como eu faria o spring gerenciar o entityManager?

Se eu quiser usar só o Pico mesmo assim preciso do jar do Spring?

@wariows
Por enquanto não há integração com o spring da sua própria aplicação (o que vc configura no applicationContext.xml),
mas você pode gerenciar facilmente criando um @Component @ApplicationScoped para criar o EntityManagerFactory
e um @Component @RequestScoped para criar os EntityManagers cada requisição… Essa integração com seu spring
vai sair num próximo release…

@edufa
Se você for usar o Pico, não precisa do jar do spring… e vice-versa
e é só colocar no seu web.xml:

<context-param>
        <param-name>br.com.caelum.vraptor.provider</param-name>
        <param-value>br.com.caelum.vraptor.ioc.pico.PicoProvider</param-value>
 </context-param>

Hummm,

Beleza, acho que ainda tem mta coisa pra sair pro vraptor3. Vou esperar sair a documentação completa, mas gostei do que vi.

Pois é, parece que hoje em dia basta montar uma URL “bonitinha” pra sair dizendo que suporta REST.

mochuara:

wariows:

Achei bem legal alguns pontos como o suporte fácil a rest…

Pois é, parece que hoje em dia basta montar uma URL “bonitinha” pra sair dizendo que suporta REST.

De forma alguma, até onde eu vi, o vraptor provê mta coisa pra teu recurso ser restful, não é apenas a ‘url bonitinha’…
Além do mais todo mundo sabe o problema de passar os parametros pela query string como por exemplo o cache…

Mas o vraptor provê anotações de fácil uso para identificar qual método do http deve ser usado para o método da lógica, o que é bem interessante em rest, usar os verbos do http com sua semântica correta.

wariows:

De forma alguma, até onde eu vi, o vraptor provê mta coisa pra teu recurso ser restful, não é apenas a ‘url bonitinha’…
Além do mais todo mundo sabe o problema de passar os parametros pela query string como por exemplo o cache…

Mas o vraptor provê anotações de fácil uso para identificar qual método do http deve ser usado para o método da lógica, o que é bem interessante em rest, usar os verbos do http com sua semântica correta.

Não tem muito a ver com REST, mas com suporte ao HTTP. Não há porque usar os termos como se fossem intercambiaveis, a nao ser porque REST ta mais na moda.

mochuara:

wariows:

Achei bem legal alguns pontos como o suporte fácil a rest…

Pois é, parece que hoje em dia basta montar uma URL “bonitinha” pra sair dizendo que suporta REST.

Ola Mochuara

Voce tem razao, muita gente usa o termo REST em vez de “nice urls” ou “routes”, mas creio que voce nao teve tempo de passar por toda a documentaca, o vraptor suporta o binding de metodos java para metodos http, ou atraves do _method. Tambem aceita o responds_with para devolver json/html/xml e esses outros headers e parametros que tem ficado popular. Estamos usando o termo rest da mesma maneira que a jsr 311 o faz. É um pouco mais que apenas urls bonitinhas.

abracos!