Use CDI no seu próximo Projeto Java

[Rafael Ponte]

Post muito bom da Caelum, vale a pena ler.

http://blog.caelum.com.br/use-cdi-no-seu-proximo-projeto-java/

Eu sinceramente acho que o CDI conseguiu superar o Spring em termos de design e até simplicidade, porém a stack do Spring continua, na minha opinião, muito mais completa, principalmente no módulo Spring Testing, na qual nos permite escrever testes de integração facilmente sem necessidade de qualquer modificação no código de produção.

Enfim, continuo preferindo o Spring :-)

--
Rafael Ponte
http://www.triadworks.com.br

[Fabricio Lemos]

O CDI é muito legal. Já o utilizei em vários projetos, desde o draft da spec, e até agora nenhum arrependimento. Eu nunca morri de amores pelo Spring, muito pelo contrário. O Seam 2 tem uma injeção de dependências bacana, mas você tinha que trazer toda uma tralha junto com ele e a complexidade poderia aumentar desnecessariamente. O CDI é impressionante como é simples, flexível e poderoso.

Quantos aos testes, os beans são POJO, então nenhuma dificuldade para os de unidade. Testes de integração, os únicos que faço são os de integração com o banco. Utilizo o DbUnit com Unitils, então nenhuma dificuldade aí também. Estou agora querendo fazer testes de integração nos meus web-services (testes de unidade e funcionais não estão caindo muito bem com eles) e vou dar uma outra olhada no Arquillian, que assim que saiu não me agradou muito mas eu o avaliei para testes de componentes de outros tipos.

Pra quem gosta de uma boa integração com a IDE, o CDI, por se aproveitar muito da tipagem nas injeções, permite muitas validações em tempo de compilação. O Jboss Tools tem uma boa integração e te antecipa no código vários dos erros que você possa ter cometido. No mais, a dica é não utilizar o CDI com o Glassfish, o servidor é todo bugado, principalmente na integração com o Weld.

abraço,
Fabrício Lemos

2012/5/24 Rafael Ponte <rpo...@gmail.com>

--
Você está recebendo esta mensagem porque se inscreveu no grupo "java.ce" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para jav...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para javace+un...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/javace?hl=pt-BR.

--
Fabrício Lemos

[Rafael Ponte]

Fabricio, como voce esta fazendo os testes de integracao? Poderia explicar melhor?

Ah, qual servidor de app voce está utilizando?

[Fabricio Lemos]

2012/5/26 Rafael Ponte <rpo...@gmail.com>

Fabricio, como voce esta fazendo os testes de integracao? Poderia explicar melhor?

É bem simples. Onde existe integração com o banco e você precisa injetar o EntityManager, você anota seu teste com o @JpaEntityManagerFactory, ele te dá uma instância do EntityManager que você injeta no seu DAO (ou qualquer outra classe que faça acesso ao banco). Daí você utiliza esta instância do EntityManager para consultar ou alterar o seu banco e o DbUnit para conferir o resultado. Funciona também se você utilizar o Hibernate direto, é só trocar o @JpaEntityManagerFactory pelo @HibernateSessionFactory. Exemplo de código você vê no "Test a JPA DAO" do Unitils. No exemplo lá, o teste está herdando do UnitilsJUnit4, mas isso não é necessário. Detalhe que ele utiliza o Spring por baixo, mas como é somente para teste, esta dependência não é passada para o seu código testado.
 

Ah, qual servidor de app voce está utilizando?

Jboss 7, que está bala :) Atualmente utilizamos a versão .org mas, por questão de suporte, passaremos em breve para a enterprise.

 

--
Fabrício Lemos

[Rafael Ponte]

Oi Fabricio,

É possível fazer isso sem nem mesmo se utilizar do Unitils, basta instanciar o EntityManagerFactory na mão e injetar o EntityManager onde necessário. O próprio Washington Botelhos (@wbotelhos) criou um toolbox para auxiliar durante os testes de integração com JPA, Hibernate e DBUnit, é o jintegrity .

Para garantir que as queries e chamadas ao banco estejam corretas isso funciona bem, mas para garantir que o controle transacional, aspectos, interceptors, DI e outros detalhes do seu container IoC é que não agrega muito. Por isso acho o Spring Testing muito bom, já que praticamente você levanta toda a camada de aplicação no ambiente de testes, ou seja, deixa o ambiente de testes mais próximo do ambiente de produção.

Se não estou enganado o Arquilian também faz o que o Spring Testing faz, mas eu nunca tive a oportunidade de trabalhar com ele.

2012/5/26 Fabricio Lemos <fabrici...@gmail.com>

--
Rafael Ponte
http://www.triadworks.com.br

[Rodrigo Galba]

Achei boa a apresentação do CDI, mas querer substitui-lo totalmente pelo Spring, foi meio que forçar a barra.
Não é preciso usar todas as APIs que o Spring disponibilizar, mas em termos de teste de integração, o Spring é melhor. Já faz tempo que ele possui essa solução. Na verdade, não sei como ficar sem esse tipo de testes, considerando que a maioria das apps do mercado envolvem banco. Imagino que ficar subindo servidor de aplicação para ver se um registro foi salvo ou consultado corretamente torna o desenvolvimento praticamente inviável. (alguem ainda faz isso?)

Sobre o arquilian, já brinquei com ele também, mas não achei tão fácil usa-lo.
E tem mais, teste unitário, mesmo com mock não substitui testes de componentes transacionais de forma satisfatória.
Sem contar que os proprios testes do Spring podem ser transacionais, e isso é muito relevante.
Testes de *WS e JMS, por exemplo, realmente são bastante simples.

@Fabricio
Fiquei curioso em ver como o CDI+Hibernate+Unitils funcionariam, mas ainda sobre as transações na aplicação, elas devem ser controladas programaticamente?

Resumindo, ainda vou de Spring.

2012/5/28 Rafael Ponte <rpo...@gmail.com>

--
--------------------------------------------
http://about.me/rgalba

[Fabricio Lemos]

2012/5/28 Rafael Ponte <rpo...@gmail.com>

Oi Fabricio,

É possível fazer isso sem nem mesmo se utilizar do Unitils, basta instanciar o EntityManagerFactory na mão e injetar o EntityManager onde necessário. O próprio Washington Botelhos (@wbotelhos) criou um toolbox para auxiliar durante os testes de integração com JPA, Hibernate e DBUnit, é o jintegrity .

Tudo o que o Unitils faz dá pra você fazer na mão também. Como o próprio nome sugere, ele é uma típica bibliotecas de utilidades que acho válido utilizar por estas e outras facilidades.
 

Para garantir que as queries e chamadas ao banco estejam corretas isso funciona bem, mas para garantir que o controle transacional, aspectos, interceptors, DI e outros detalhes do seu container IoC é que não agrega muito. Por isso acho o Spring Testing muito bom, já que praticamente você levanta toda a camada de aplicação no ambiente de testes, ou seja, deixa o ambiente de testes mais próximo do ambiente de produção.

Estes tipos de testes de integração: "controle transacional, aspectos, interceptors, DI e outros detalhes do seu container IoC" é que eu não faço e não lembro a ultima vez que tive problemas com isso. São coisas que hoje em dia são tão simples de se configurar que, se der algum erro, provavelmente não foi do meu código, e sim algum bug do container. Por exemplo, eu não testo, para todas as injeções, se a instância injetada pelo container é a que realmente deveria ser injetada. De qualquer forma, meu testes funcionais acabam pegando alguma coisa que deixei passar.

 

--
Fabrício Lemos

[Fabricio Lemos]

2012/5/28 Rodrigo Galba <rodrig...@gmail.com>

Achei boa a apresentação do CDI, mas querer substitui-lo totalmente pelo Spring, foi meio que forçar a barra.

É justamente isso que o pessoal está querendo :) Claro que o Spring ainda possui muito mais componentes do que o CDI, mas isso é mais pela idade e maturidade do Spring do que pela superioridade de seu container.
 

Não é preciso usar todas as APIs que o Spring disponibilizar, mas em termos de teste de integração, o Spring é melhor. Já faz tempo que ele possui essa solução. Na verdade, não sei como ficar sem esse tipo de testes, considerando que a maioria das apps do mercado envolvem banco. Imagino que ficar subindo servidor de aplicação para ver se um registro foi salvo ou consultado corretamente torna o desenvolvimento praticamente inviável. (alguem ainda faz isso?)

Como falei antes, mesmo sem utilizar o Spring não é preciso subir servidor de aplicação para testar sua persistência.
 

Sobre o arquilian, já brinquei com ele também, mas não achei tão fácil usa-lo.
E tem mais, teste unitário, mesmo com mock não substitui testes de componentes transacionais de forma satisfatória.
Sem contar que os proprios testes do Spring podem ser transacionais, e isso é muito relevante.
Testes de *WS e JMS, por exemplo, realmente são bastante simples.

@Fabricio
Fiquei curioso em ver como o CDI+Hibernate+Unitils funcionariam, mas ainda sobre as transações na aplicação, elas devem ser controladas programaticamente?

O próprio Unitils controla isso. Não é muito complicado, basicamente o que ele faz é criar um escopo de transação para cada teste.
 

--
Fabrício Lemos

[Rodrigo Galba]

2012/5/28 Fabricio Lemos <fabrici...@gmail.com>

2012/5/28 Rodrigo Galba <rodrig...@gmail.com>

Achei boa a apresentação do CDI, mas querer substitui-lo totalmente pelo Spring, foi meio que forçar a barra.

É justamente isso que o pessoal está querendo :) Claro que o Spring ainda possui muito mais componentes do que o CDI, mas isso é mais pela idade e maturidade do Spring do que pela superioridade de seu container.
 

Não é preciso usar todas as APIs que o Spring disponibilizar, mas em termos de teste de integração, o Spring é melhor. Já faz tempo que ele possui essa solução. Na verdade, não sei como ficar sem esse tipo de testes, considerando que a maioria das apps do mercado envolvem banco. Imagino que ficar subindo servidor de aplicação para ver se um registro foi salvo ou consultado corretamente torna o desenvolvimento praticamente inviável. (alguem ainda faz isso?)

Como falei antes, mesmo sem utilizar o Spring não é preciso subir servidor de aplicação para testar sua persistência.
 

Sobre o arquilian, já brinquei com ele também, mas não achei tão fácil usa-lo.
E tem mais, teste unitário, mesmo com mock não substitui testes de componentes transacionais de forma satisfatória.
Sem contar que os proprios testes do Spring podem ser transacionais, e isso é muito relevante.
Testes de *WS e JMS, por exemplo, realmente são bastante simples.

@Fabricio
Fiquei curioso em ver como o CDI+Hibernate+Unitils funcionariam, mas ainda sobre as transações na aplicação, elas devem ser controladas programaticamente?

O próprio Unitils controla isso. Não é muito complicado, basicamente o que ele faz é criar um escopo de transação para cada teste.

Não fui claro. Estou perguntando como resolver a parte transacional da minha app sem ser programaticamente? Utilizando lib de terceiros? Com Spring, essa configuração é toda declarativa.
 

--
--------------------------------------------
http://about.me/rgalba

[Rodrigo Galba]

2012/5/28 Fabricio Lemos <fabrici...@gmail.com>

2012/5/28 Rafael Ponte <rpo...@gmail.com>

Oi Fabricio,

É possível fazer isso sem nem mesmo se utilizar do Unitils, basta instanciar o EntityManagerFactory na mão e injetar o EntityManager onde necessário. O próprio Washington Botelhos (@wbotelhos) criou um toolbox para auxiliar durante os testes de integração com JPA, Hibernate e DBUnit, é o jintegrity .

Tudo o que o Unitils faz dá pra você fazer na mão também. Como o próprio nome sugere, ele é uma típica bibliotecas de utilidades que acho válido utilizar por estas e outras facilidades.
 

Para garantir que as queries e chamadas ao banco estejam corretas isso funciona bem, mas para garantir que o controle transacional, aspectos, interceptors, DI e outros detalhes do seu container IoC é que não agrega muito. Por isso acho o Spring Testing muito bom, já que praticamente você levanta toda a camada de aplicação no ambiente de testes, ou seja, deixa o ambiente de testes mais próximo do ambiente de produção.

Estes tipos de testes de integração: "controle transacional, aspectos, interceptors, DI e outros detalhes do seu container IoC" é que eu não faço e não lembro a ultima vez que tive problemas com isso. São coisas que hoje em dia são tão simples de se configurar que, se der algum erro, provavelmente não foi do meu código, e sim algum bug do container. Por exemplo, eu não testo, para todas as injeções, se a instância injetada pelo container é a que realmente deveria ser injetada. De qualquer forma, meu testes funcionais acabam pegando alguma coisa que deixei passar.

Realmente não testo se a DI esta funcionando como deveria. Isso é consequencia do teste. Deixar que os testes funcionais peguem essa integração é um nível muito alto para testar a modelagem do codigo, e das partes do dominio.
Mesmo os testes unitarios fazendo isso, problemas que os testes de integração pegam.
Acho que testes funcionais não tem essa intenção.
 

--
--------------------------------------------
http://about.me/rgalba

[Rodrigo Galba]

Resumindo, a intenção de simplificar uma app com CDI é valida, mas existem questões como transações e teste de integração que precisam ser resolvidas.
De acordo com o titulo do post, entendo que a sugestão de usar CDI no lugar do Spring, deveria pelo menos sugerir soluções para pontos como esses.

2012/5/28 Rodrigo Galba <rodrig...@gmail.com>

--
--------------------------------------------
http://about.me/rgalba

[Odilio Noronha]

Me pareceu mais um post de iniciação ao CDI e não um post voltado a realmente mostrar como a solução pode ser completa substituindo toda a stack do spring, gostei do post!

[Fabricio Lemos]

2012/5/28 Rodrigo Galba <rodrig...@gmail.com>

Resumindo, a intenção de simplificar uma app com CDI é valida, mas existem questões como transações e teste de integração que precisam ser resolvidas.

Para transações o que eu faço, e o mais natural, é utilizar a própria plataforma JEE, ou seja, EJB 3.1. Caso não queira utilizar EJB, você pode utilizar componentes como o Seam 3 Persistence ou o Apache CODI.

Quanto aos testes de integração, não é minha intenção substituí-os pelos funcionais. Teste de integração com o banco de dados dá pra fazer tranquilamente. Outros testes de integração são os que falei que geralmente eu não sinto necessidade de fazer. Se um dia a configuração de DI, transação, interceptors, etc ficar tão complicada que meu código passe a ter bug nisso aí, acho que tá na hora de trocar de container. Sobre o que falei de testes funcionais pegarem os erros, é efeito colateral. Por exemplo, se eu declaro erroneamente a injeção de uma dependência, o erro jã acontece no deploy. Mesmo não sendo o ideal, o erro não passa batido.

 

--
Fabrício Lemos

[Rafael Ponte]

Oi Fabricio,

Se você tratar sempre os componentes (beans) que precisam de testes de integração de maneira isolada eu acho difícil você precisar de uma ambiente mais "real".

A coisa realmente só exige algo mais "real container" quando queremos ver nossos interceptors, aspectos, error-handlers, controle transacional fino em ação, ou seja, quando queremos ter certeza que está tudo em harmônia.

Mas se você e sua equipe realmente não sentem atualmente necessidade então não vejo problema continuar assim. O mais importante é que você estão escrevendo testes automatizados :-)

[Rafael Ponte]

Ah, sobre Arquillian, saiu um post na InfoQ este mês,

http://www.infoq.com/articles/dan-allen-arquillian-framework

Vale a pena a leitura.