Assim, durante o artigo o leitor terá uma visão geral do DeltaSpike, permitindo conhecer as suas principais funcionalidades e entender o porquê deste projeto ser tão inovador. A partir deste panorama, será possível identificar quais das diversas funcionalidades podem ser úteis às suas soluções CDI.
É inegável dizer que a especificação CDI mudou definitivamente a forma de desenvolver softwares utilizando Java. O conceito de injeção de dependências, que desde o princípio é disseminado como princípio (e boa prática) na orientação a objetos, passou a ser um cidadão de primeira classe. Além da injeção de dependências, a capacidade de disponibilizar Beans que possuem um ciclo de vida bem definido, fizeram com que o CDI se tornasse um dos assuntos mais falados ultimamente em blogs, artigos e apresentações nos diversos eventos de tecnologia.
Já na versão CDI 1.0 (JSR 299), o Expert Group foi muito feliz em especificar como parte das funcionalidades um importante princípio da programação orientada a objetos: O princípio OCP (Open Closed Principle). Este determina que os objetos devem ser abertos para extensão e fechados para modificação.
No CDI esta funcionalidade recebeu o nome de Portable Extensions. Esta funcionalidade permite que o CDI seja estendido ao ponto de ter seu comportamento modificado, possibilitando que novas funcionalidades sejam disponibilizadas através do registro dinâmico de novos Beans CDI, da modificação dos metadados (qualifiers, alternatives e interceptors) de beans existentes e da criação de novos contextos.
Não tardou para que diversas comunidades Java e organizações percebessem que o CDI poderia ser utilizado também como um alicerce para frameworks ou para integração com seus produtos e tecnologias existentes. Com isto, diversas iniciativas em paralelo se espalharam rapidamente.
Projetos como o JBoss Seam 3, Apache MyFaces CODI e CDISource tornaram-se grandes (no sentido de quantidade e qualidade) repositórios de extensões CDI. No início, isto só provava que a especificação CDI se tornou um sucesso, por prover um verdadeiro ecossistema para desenvolvedores.
Entretanto, no final de 2011, as comunidades formadas pela Red Hat, Apache e CDISource resolveram unir seus esforços e criar um conjunto de extensões CDI de forma padronizada e combinando as melhores funcionalidades de cada um destes projetos.
Logo após, no começo de 2012, foi anunciado o projeto DeltaSpike. Este projeto foi incubado dentro da Fundação Apache até maio de 2013, quando então se tornou um projeto de primeiro nível. Mesmo antes do lançamento da sua versão final, o DeltaSpike já estava sendo utilizado por outros projetos, como o PicketLink, da Red Hat.
A versão 1.0 do DeltaSpike foi lançada em junho deste ano e praticamente dois meses depois foi anunciado no JavaOne 2014 (em setembro) que o projeto levava para casa uma estatueta do Duke's Choice Award. Desde então, esta solução vem ganhando cada vez mais usuários, colaboradores e contribuições.
Na Figura 1 é possível ter um panorama da história do projeto.
Figura 1. Panorama histórico do projeto DeltaSpike.
Essencialmente, o DeltaSpike é um conjunto de extensões para o CDI, contendo funcionalidades úteis que não estão disponíveis na especificação. Com o objetivo de manter um agrupamento lógico destas extensões, o projeto é composto por um módulo principal e vários módulos opcionais, a saber:
· Core: É o módulo principal do DeltaSpike, o único que é obrigatório. Fornece funcionalidades como Configuration API, Type-safe ProjectStage e I18n, a anotação @Exclude, um framework de tratamento de exceções, etc.;
· Security: Módulo que fornece um mecanismo de segurança usando anotações;
· JPA: É o módulo que permite que Beans CDI façam parte de um contexto transacional (assim como os EJBs) através do uso da anotação @Transactional. Este módulo também declara o contexto @TransactionScoped, que determina que o ciclo de vida de um Bean CDI é inicializado e finalizado junto com a transação;
· Data: Módulo que traz funcionalidades como a implementação do padrão Repository, fornecendo acesso a dados de forma declarativa e reduzindo drasticamente o código necessário. Este módulo também fornece funcionalidade de auditoria de entidades JPA;
· JSF: Módulo que fornece novos escopos CDI (WindowScoped, ViewScope, ViewAccessScoped e GroupedConversationScoped), bem como a possibilidade de configuração de metadados (relacionados à segurança, navegação, redirecionamento, extensão, etc.) das páginas JSF (view-config) de forma programática. Além disso, permite que classes da especificação JSF, como Converters e Validators, possam receber a injeção de Beans CDI;
· Bean-Validation: Módulo que permite a injeção de objetos CDI e EJBs em validadores;
· Servlet: Módulo que viabiliza a injeção de objetos Servlet e a propagação dos eventos do ciclo de vida do Servlet para o CDI;
· Partial Bean: Módulo que permite criar proxies para interfaces e classes abstratas que terão o mesmo comportamento de beans CDI. Esta funcionalidade ajuda na criação de beans CDI sem a necessidade de implementar uma interface ou classe abstrata diretamente;
· Scheduler: Módulo que fornece uma integração com o Quartz de maneira a facilitar o agendamento de Jobs e também permitir a injeção de objetos CDI;
· Container & Control / Test-Control: Ambos os módulos permitem a inicialização e paralisação de containers CDI em ambientes Java SE, além de controlar o ciclo de vida dos contextos e facilitar a escrita de testes para componentes CDI.
A relação do DeltaSpike com o Java EE 7 e o CDI 1.1
Além de ser esta enorme coleção de extensões para o CDI, o DeltaSpike também age como um fomentador da evolução desta especificação. Muitas funcionalidades que hoje já estão disponíveis no Java EE 7, inclusive, tiveram seu início no DeltaSpike. Vejamos alguns exemplos:
· A anotação @Transactional para POJOs;
· A anotação @Vetoed do Java EE 7 existe no DeltaSpike como @Exclude;
· Permitir a injeção de Beans CDI nos EntityListerners da especificação JPA e nas classes que realizarão a validação na especificação Bean Validation;
· O escopo de visão (@ViewScoped), onde os Beans são descartados quando o usuário navega para outra página. Esta solução já estava disponível no DeltaSpike antes mesmo de tornar-se presente na especificação JSF 2.2.
A Figura 2 apresenta todos os módulos que compõem o DeltaSpike. Os módulos representados na cor azul contêm apenas funcionalidades ímpares, que sequer foram especificadas no CDI. Já o módulo na cor verde contém funcionalidades que já estão presentes no CDI 1.1, mas que graças ao DeltaSpike podem ser executadas em ambientes Java EE 6/CDI 1.0.
A cor alaranjada sinaliza os módulos que possuem funcionalidades já presentes no CDI 1.1 e também outras funcionalidades inéditas. Por possuir funcionalidades já implementadas no Java EE 7, algumas pessoas podem ser levadas a se perguntar o porquê utilizar o DeltaSpike.
Neste momento é bom lembrar que em ambientes corporativos o uso de servidores Java EE 7 suportados e homologados pode levar alguns anos e, nestes casos, usando o DeltaSpike, algumas destas funcionalidades do Java EE 7, bem como inúmeras outras funcionalidades, já estarão disponíveis no seu servidor Java EE 6, permitindo assim que seu código esteja atualizado e facilitando um futuro upgrade, além, é claro, das demais possibilidades e facilidades que o DeltaSpike disponibiliza.
Figura 2. Módulos do DeltaSpike e suas relações com o CDI 1.1.
Instalando o DeltaSpike em seu projeto
A instalação do DeltaSpike pode ser feita de forma manual através do download (veja o endereço na seção Links) do pacote e cópia dos arquivos JAR para o CLASSPATH da aplicação. Os módulos do DeltaSpi ...