CDI. Injeção de Dependência e Gerenciamento de Contextos no Java EE 6

Transcrição

1 artigo CDI Injeção de Dependência e Gerenciamento de Contextos no Java EE 6 Alessandro Lazarotti (alazarot@redhat.com) Instrutor e consultor na divisão JBoss da Red Hat Brasil. Trabalha com Java Corporativo desde 2003 envolvido com arquitetura, análise, P&D de soluções baseadas em open source e lecionando treinamentos e workshops sobre tecnologia em geral. á algum tempo na plataforma Java, a utilização de frameworks que proveem uma implementação do pattern Dependency Injection (DI), ( html#inversionofcontrol) tem sido uma prática comum em vários projetos. Baixo acoplamento entre objetos, facilidade na criação de testes, códigos mais limpos são algumas das muitas vantagens na utilização deste pattern. Porém, por não serem soluções baseadas em especificações, cada framework possui sua maneira própria de trabalhar com DI, sendo muitas vezes incompatíveis entre si. No JavaEE 6, com a padronização da injeção de dependência, seu poder é levado ao extremo podendo ser utilizado de maneira intercambiada entre classes java convencionais (POJOs) e componentes como Servlets, EJBs e Managed Beans. Agora é possível injetar um EJB em uma classe java simples, entre outras funcionalidades. J 0 SFTQPOTÈWFM QPS FTUB OPWJEBEF Ï B +43 i$poufyut BOE %FQFOEFODZ Injection for the JavaTM EE platform, ou simplesmente CDI. Esta nova especificação dita a interação entre os tradicionais componentes JavaEE e POJOs em uma aplicação, além de definir o ciclo de vida de tais instâncias através da declaração de escopos para seus objetos gerenciados. Uma entre as mais aguardadas novidades dentro da nova plataforma JavaEE 6 é a especificação CDI. Trazendo ideias de frameworks, como Google Guice e JBoss Seam, o CDI promete revolucionar o modelo atual de desenvolvimento de sistemas corporativos. Este artigo apresentará, por meio de exemplos, os principais aspectos desta especificação. CDI também é responsável por: t 1FSNJUJS RVF RVBMRVFS VN EF TFVT PCKFUPT HFSFODJBEPT TFKBN BDFTsíveis diretamente por uma interface JSF ou JSP através de Unified Expression Language (EL). t 0GFSFDFS OPWP NFDBOJTNP EF EFDMBSBÎÍP EF JOUFSDFQUBEPSFT GSBDBmente acoplados. t )BCJMJEBEF EF iefdpsbsw PCKFUPT JOKFUBEPT t 6N NPEFMP EF OPUJmDBÎÍP EF FWFOUPT t 6N OPWP DPOUFYUP XFC TPNBOEP BP 3FRVFTU "QQMJDBUJPO F 4FTsion, chamado de Conversation. t 'PSOFDFS VN DPOKVOUP EF 41* 4FSWJDF 1SPWJEFS *OUFSGBDF QBSB QPTsibilitar extensões portáveis. A implementação de referência desta especificação é mantida pela divisão JBoss da Red Hat, sob o nome Weld, e está hospedado no mesmo domínio do Seam Framework (ver em referências). Vamos começar a explorar os aspectos do CDI por sua base, a definição de um objeto gerenciável por esta especificação, o Bean. 35

2 Você precisa de Beans Para habilitar o CDI em uma aplicação ou serviço JEE 6, deve-se inserir no projeto o arquivo: META-INF/beans.xml. Este arquivo, mesmo vazio, é o que será rastreado por um servidor de aplicação para associar os serviços do CDI com o pacote implantado, seja jar, war ou ear. Uma vez tendo uma aplicação CDI, todos os beans do projeto passam a ser gerenciados pelo servidor de aplicação. Mas o que é de fato um bean? O JavaEE 6 define dois tipos de beans passíveis de serem manipulados pelo CDI: Managed Beans e Session Beans. Managed Beans Diferente do que possa parecer pela semelhança na nomenclatura, essa categoria de bean não tem algo haver com JSF. No CDI, um bean do tipo Managed Bean é qualquer classe java que: Como pode ser observado, a maioria dos POJOs podem ser encarados como sendo Managed Beans, sendo que nenhuma anotação extra é necessária para tal. Uma vez encontrado o arquivo beans.xml, qualquer classe java com as características acima passam a ser gerenciadas pelo CDI. A nova especificação define também que qualquer Managed Bean suporta a implementação dos métodos de callback a seu ciclo de vida, (invocado antes da instância do bean ser destruída). Um servlet container, como o Tomcat, não é obrigado por especificação a possuir suporte a CDI, mas implementações desta especificação, como o Weld, possuem extensões que possibilitam o deploy neste tipo de ambiente. A principal diferença de uma aplicação CDI em um servlet container ou em um servidor de aplicação JavaEE 6, é que no último os beans do tipo Managed Beans podem se valer de enquanto nos servlet containers você pode não se valer, por exemplo, de serviços como injeção de contexto de persistência. O novo web profile, exigido pela especificação JavaEE 6 para servidores de aplicações, possui suporte a CDI. Session Beans Session Beans são componentes gerenciados pelo servidor de aplicação definidos pela especificação Enterprise JavaBeans (ver nesta edição o artigo mais seu gerenciamento de estado é sua especificação e não o CDI. Contudo, todas as funcionalidades expostas para um bean do tipo Managed Bean também é válida para o bean do tipo Session Bean, como injeção de dependência, notificação de eventos, CDI Interceptors e CDI Decorators. Uma vez que tanto Managed Beans quanto Session Beans são considerados CDI Beans, um pode ser injetado ou responder a eventos disparados pelo outro, sem qualquer distinção ou restrição. Dependency Injection public class RelatorioGerencial{ RelatorioGerencial relatoriogerencial; public void gerarrelatorio() { Nesta primeira listagem, é injetado o bean RelatorioGerencial no bean foi preciso inserir nenhuma anotação de classe especial, já que por definição ambas as classes obedecem ao padrão managed beans do CDI. Toda DI na especificação é baseada nos tipos dos beans. No exemplo da injetado. Isso é diferente de frameworks como o JBoss Seam até sua ver- também válido para injetar RelatorioGerencial em RelatorioService. public class RelatorioGerencial Nesta listagem, RelatorioGerencial também é injetado em RelatorioService, uma vez que ele implementa a interface Relatório. É correto afirmar que RelatorioGerencial é um tipo de: (a) Object (de maneira implícita, 36

3 Desta forma, ele é elegível para qualquer tentativa de injeção na qual um destes tipos é o alvo a ser injetado. Restrigindo tipos O desenvolvedor pode optar por restringir apenas qual tipo da sua hierarquia poderá ser elegível para alguma injeção. Isso é realizado através Listagem 3. Restringindo o bean ao tipo public class RelatorioGerencial Restringindo o tipo do bean, apenas alvos a serem injetados que correspondem com exatidão aquele tipo receberão sua instância, independentemente de sua classe pai ou interface. Desta forma, o bean Relatorio- Gerencial, como é declarado na Listagem 3, não poderia ser injetado em de deployment. Resolvendo ambiguidades existe mais de um bean que satisfaz um mesmo alvo de injeção, podemos ter outro problema. A Listagem 4 ilustra essa situação. Listagem 4. Tipos ambíguos. public class RelatorioGerencial public class RelatorioFuncional implements Relatorio{ requer algum Relatorio? Na verdade, nenhum, pois um erro em tempo de deployment mencionando: Injection point has ambiguous dependencies será lançado. Para o CDI poder realizar a resolução de qual bean deve ser injetado, o desenvolvedor deve fornecer no momento da injeção uma segunda anotação para desfazer a ambiguidade. A base para essa anotação é uma implementa- para dizer qual o bean correto a ser aplicado em determinada injeção. Na realidade todo bean que não possui um qualificador, ou seja, não - * Criando anotação Gerencial, do tipo Gerencial { * Criando anotação Funcional, do tipo Funcional{ * Definindo um bean como public class RelatorioGerencial * Definindo um bean como public class RelatorioFuncional * Resolvendo Relatorio relatorio; Mais sobre a CDI Dependency Injection Como pode ser observado, a especificação CDI define uma maneira bem controlada de resolução de tipos a serem injetados nas dependências de um bean. O nome ostentado pela especificação quanto ao algoritmo utilizado é Typesafe Resolution. A influência direta por tal mecanismo tipado para DI é o framework Google Guice, e as vantagens são muitas: prevenção contra erros de injeção em tempo de execução, apoio de ferramentas IDE para produtividade, clareza nos códigos, entre outros. De maneira geral, a injeção é realizada de três formas: injeção por atributo, por método set ou por construtor. Em qualquer um dos modos, é possível utilizar qualifiers para resolver ambiguidades na injeção. A Listagem 6 exemplifica os tipos de injeção. 37

4 Listagem 6. Tipos de injeção. //injeção por método public void setrelatorio(relatorio relatorio) { this.relatorio = relatorio; //injeção por public RelatorioService(Relatorio relatorio) { this.relatorio = relatorio; //injeção por construtor usando public RelatorioService(@Gerencial Relatorio Relatorio relatoriofuncional) { this.relatoriogerencial = relatoriogerencial; this.relatoriofuncional = relatoriofuncional; Beans contextuais O desenvolvedor de aplicações web está acostumado a lidar com escopos request, session ou application. Chamamos o conjunto de objetos associados a estes escopos de contexto ou, em inglês, Context. No CDI, todo bean está necessariamente dentro de algum contexto, que delimita sua visibilidade para o resto da aplicação (incluindo os aspectos relacionados à DI). A Listagem 7 exibe um bean em escopo de sessão. Listagem 7. Bean no escopo de private Relatorio relatorio; Sempre que ocorrer a alteração de estado de um bean, isso se reflete em seu contexto. Todos que possuírem uma referência a este mesmo bean através de DI pelo seu escopo, terá este seu novo estado na instância. O CDI especifica quatro tipos de escopos: ser ela: invocações ao método service() de qualquer Servlet ou dofil- - Listagem 8. Bean no de mensagens para algum EJB MDB. É de visibilidade exclusiva a cada cliente do contexto, não podendo, portanto, compartilhar o estado de suas instâncias com múltiplos clientes. A duração do contexto atrelado a este escopo é de apenas uma requisição. método service() de qualquer Servlet ou dofilter() de qualquer servlet tlistener ou AsyncListener. Assim como RequestScoped, tem visibilidade exclusiva a cada cliente. A duração do contexto atrelado a este escopo é a mesma da sessão web de um usuário, podendo ser destruída por seu timeout ou por chamada a httpsession.invalidate(). de web service, invocações remotas e assíncronas de EJB, execução de EJB timeouts, entregas de mensagens JMS e execução de listeners como ServletContextListener, HttpSessionListener, AsyncListener ou ServletRequestListener. Este escopo é compartilhado por todas as threads de uma aplicação, ou seja, todos os usuários têm a mesma visibilidade do estado de objetos sobre este escopo. O contexto para este escopo é destruído quando a aplicação se encontra em estado indisponível. quer request JSF, porém pode ser extendido através da CDI SPI (Service Provider Interface) para outros frameworks web. O contexto Conversation geralmente é encarado como um meio-termo entre Session e Request, podendo armazenar o estado dos beans entre múltiplas requisições, exclusiva ao cliente, mas por um período menor do que a sessão. Tal período pode ser definido por timeout ou por demarcação programática da vida útil deste contexto, através da invocação dos métodos conversation.begin() e conversation.end(). A Listagem 8 exibe um bean em escopo de conversação com estas Relatorio relatorio; Conversation conversation; // outros atributos public void gerarrelatorio(.. ){ conversation.begin(); public void downloadrelatorio(.. ){ public void destroy() { 38

5 No exemplo da Listagem 8, um bean do tipo Stateful SessionBean foi utilizado com o escopo Conversation. Quando for executado o método gerarrelatorio(), o estado deste bean será mantido no contexto de conversação independentemente do número de requisições posteriores. Ao executar downloadrelatorio(), o estado do objeto será descartado, então o próprio CDI irá invocar nitivamente a instância do Session Bean. O nome dado na especificação para este tipo de comportamento em uma conversação, demarcado pelas fronteiras conversation.begin() e conversation.end() é Long-Running Conversation. Esta é uma rara situação na qual o desenvolvedor é capaz de controlar o ciclo de vida de um bean. Nos outros contextos, a gerência do estado de uma instância e sua destruição é dada sempre pelo container. Embora um Session Bean seja utilizado nesta listagem, também poderia ser ve (mas lembre-se, o desenvolvedor não poderá se valer de serviços exclusivos a EJBs como thread pooling, chamada assíncrona, passivação gerenciada por um servidor de aplicação etc. ). Se a demarcação conversation.begin() não for definida em algum método, como em gerarrelatorio() da Listagem 8, a conversação será do tipo transiente e irá durar o ciclo de apenas um request. O pseudo escopo Dependent Como já mencionado, todo bean CDI é contextual. Mesmo se não for definido explicitamente um escopo para o objeto, ele receberá de forma implícita o cha- ciclo de vida dependente do escopo do objeto a qual ele é injetado, quando do CDI, é correto afirmar que um objeto do tipo RelatorioGerencial é um mana- Porém, mesmo se um bean possuir um escopo definido, ainda sim é possível injetá-lo de forma dependente ao contexto de outro bean, através public class private Relatorio @Gerencial Relatorio novorelatorio; latoriogerencial, um no contexto session e outro (novorelatorio) no contexto request, por possuir escopo dependente. Produzindo Beans class Configuracao { private TipoDeRelatorio Relatorio obtemrelatorio(){ switch (tipoderelatorio) { case GERENCIAL: return new RelatorioGerencial(); case FUNCIONAL: return new RelatorioFuncional(); default: return private Relatorio relatorio; class Configuracao { private TipoDeRelatorio Relatorio obtemrelatorio( RelatorioGerencial gerencial, RelatorioFuncional funcional){ switch (tipoderelatorio) { case GERENCIAL: return gerencial; case FUNCIONAL: return funcional; default: return null; Como já descrito, chamamos de bean no CDI classes Java simples, com as restrições definidas no começo deste artigo, além dos Session Beans. Entidades JPA que possuem ciclo de vida gerenciado por um contexto de persistência ou classes da própria API da linguagem Java, como coleções, não são por natureza beans. Contudo, é possível expormos qualquer tipo de classe como beans con- 39

6 ferramenta poderosa de polimorfismo, mudando o comportamento de sua como um método fábrica. Um detalhe nesta listagem é que as implementações de Relatório são geradas a partir do operador java new, e não pelo CDI. Desta forma, no momento que são instanciados não é possível utilizar interceptadores CDI ou realizar algum tipo de injeção em seus construtores. Para driblar isso, podemos utilizar injeção Outra forma de expor rapidamente um objeto como managed bean, é - class Configuracao @Desenvolvedor static String dev = Lazarotti ; Destruindo Beans public class RelatorioEntityManager RelatorioDataBase ) EntityManagerFactory emf; Nesta listagem, o método encerrar é chamado automaticamente pelo CDI quando a conversação associada ao bean EntityManager com quali- public class LoggerInterceptor { Logger logger = Interceptors Interceptors são classes que disponibilizam um pré-processamento que anteveem a execução de um método de um bean, de forma automática. Geralmente estes pré-processamentos (ou pós) são comuns a várias instâncias, o que chamamos de interesses transversais de comportamento. O maior dos problemas nas aplicações não-cdi é que o modelo de Interceptor padrão na plataforma Java EE 5 é intrusivo. Veja um public Object logar(invocationcontext context) { logger.debug( Executando o metodo + context.getmethod()); @RelatorioDataBase public EntityManager criar() { return emf.createentitymanager(); public void EntityManager entitymanager) { return emf.createentitymanager(); Um bean sempre é destruído pelo CDI. Quando um contexto se encerra, como um final de request ou de sessão, por exemplo, os bens são finalizados apropriadamente pelo ciclo de vida CDI. Contudo, quando um bean é inicializado momento em que o bean é destruído, assim recursos alocados na criação da instância podem ser encerrados de maneira correta nestes. Nesta listagem todos os métodos de RelatorioService serão interceptados por LoggerInterceptor, incluindo gerarrelatorios(). Um problema visível nesta tradicional implementação é que a classe RelatorioService está atrelada de forma muito forte a LoggerInterceptor, o que pode dificultar tarefas como codificação de testes. Inspirado no modelo de interceptadores presentes no framework JBoss Seam, o CDI traz em sua especificação um modelo menos acoplado para a codificação, chamado de Interceptor Bindings, além de fornecer um modo Note que em nenhum momento é colocado de forma explícita a utilização de LoggerInterceptor para RelatorioService. Todos interceptors no CDI são por padrão desabilitados. Para habilitar um interceptor é necessário incluir a classe Interceptor dentro do arquivo beans. 40

7 A ordem em que os interceptors aparecem no arquivo beans.xml é a ordem de execução dos mesmos. Para remover a execução de um interceptador para determinado ambiente (de testes, por exemplo), basta removê-lo do arquivo. * Criando anotação Logged, do tipo class LoggerInterceptor { Logger logger public Object logar(invocationcontext context) { logger.debug( Executando o metodo + context.getmethod()); <beans xmlns= xmlns:xsi= xsi:schemalocation= com/xml/ns/javaee/beans_1_0.xsd > <interceptors> <class>br.com.mundoj.cdiapp.securityinterceptor</class> <class>br.com.mundoj.cdiapp.loggerinterceptor</class> </interceptors> </beans> Decorators Decorator é um padrão de projeto catalogado no livro Design Pattern: Elements of Reusable Object-Oriented Software, de quatro conhecidos autores quase sempre referenciados como Gang Of Four, ou simplesmente GoF (veja na edição anterior uma excelente entrevista com esta gangue ). Como objetivo deste padrão, está descrito: Atribuir responsabilidade adicionais a um objeto dinamicamente, é exatamente isso que o CDI proporciona ao desenvolvedor, com sua implementação de Decorator. A diferença entre um Decorator e um Interceptor é que os interceptadores são para regras comuns a vários objetos da aplicação, como: segurança, transação, log e demais serviços de infraestrutura não dependentes de regras de negócio de um objeto específico. Diferente deste aspecto, um Decorator conhece detalhes do objeto a ser interceptado (decorado) e sua implementação é dependente dos dados em tempo de execução deste objeto, podendo, com base nisso, lhe dar novas características de forma dinâmica. No CDI, a especificação dá um nome para o alvo a ser interceptado por um Decorator: Delegate Injection Point. Para melhor entender public class RelatorioServiceDecorator RelatorioService relatorioservice; service correio; if(!ehumdiautil(relatorioservice.getrelatorio().getdata()) ){ correio.enviarmensagem( Relatorio + relatorioservice.getrelatorio().getnome() + sendo gerado fora do expediente ).para(admin); // continuar com a execução relatorioservice.gerarrelatorio(); Neste exemplo, RelatorioService está sendo decorado por RelatorioService- relatório seja feita fora de um dia útil, uma mensagem é enviada para algum administrador do sistema. Veja que um objeto Decorator, assim como os Interceptors, são beans CDIs comuns, logo podem usufruir de qualquer tipo de injeção, assim como podem ser definidos um contexto para si. Se nenhum for definido, ele terá escopo dependente do escopo do bean a ser decorado. Uma das injeções em um Decorator é obrigatória, é o que se trata de Delegate Delegate em RelatorioService, define que ele é o bean a ser interceptado. em um Decorator. Um Decorator deve ter a assinatura de método idêntica ao método que se de- pode opcionalmente se valer de implementar a mesma interface do objeto decorado, ou na falta de uma interface, estender o bean e sobrescrever o método a interceptar. Pode ser processado qualquer trecho de código no método veja que o código comentado com //continuar a execução faz uma chamada explícita ao método do bean decorado, isso garante que o fluxo da execução no Decorator continue para aquela instância de bean. Com sua omissão, quando invocado o método gerarrelatorio(), sua execução iria até o Decorator e nunca seria chamado de fato o método que está no bean. 41

8 Diferente dos Interceptors, um Decorator é definido para tipos não-ambíguos. Quando é definido um Delegate Injection Point, este terá que possuir todos os Qualifiers necessários para resolver as possíveis ambiguidades e caso isso não ocorra uma exception será lançada informando ambiguidade. Se for preciso interceptar chamadas generalizadas a tipos de beans, utilize os Interceptors. Assim como os Interceptors, os Decorators precisam ser declarados em beans. <beans xmlns= xmlns:xsi= xsi:schemalocation= com/xml/ns/javaee/beans_1_0.xsd > <decorators> <class>br.com.mundoj.cdiapp.relatorioservicedecorator</class> </decorators> </beans> Eventos Embora a DI permita um código com baixo acoplamento, sem o instanciamento explícito de um objeto no código, às vezes ainda acabamos por ter que compor um objeto com outro, sem que na modelagem este relacionamento RepositorioDeRelatorios repositorio; correio;... repositorio.adicionar(relatorio); correio.enviarmesagem( O relatorio requisitado esta concluído e disponível no ftp ).para(relatorio.getusuario().get ()); Na listagem, RelatorioService possui um repositório de relatórios que pode armazenar o relatório gerado em um ftp, e então mandar um mensagem de notificando o usuário que seu relatório está disponível. Porém, para alguns arquitetos, a dependência do bean RepositorioDeRelatorios e pode não parecer o melhor dos designs para este código, isso poderia ser evitado. Outro ponto é que o método gerarrelatorio() da classe RelatorioService está com responsabilidades demais. Uma solução elegante neste caso seria aplicar um evento dizendo que o relatório está pronto, e fazer com que observadores a este evento realizem suas ações específicas de forma automática. PARAMETER) Pronto { public class RepositorioDeRelatorios { public void public class Service implements public void Relatorio relatorio){ enviar( O relatorio requisitado esta concluído e disponível no Event<Relatorio> relatorioevent;... relatorioevent.fire(relatorio); Pronto. Tanto RepositorioDeRelatorios como Service possuem observadores de eventos, para quando um relatório atingir o estado de pronto realizar Deve-se injetar a interface javax.enterprise.event.event, seguida de um qualifer do evento na classe responsável por executar a ação a ser capturada fire(event) que de fato irá disparar o evento. Acessando beans em páginas web É possível acessar beans CDI de qualquer meio que suporte a notação Java de Expression Language (EL), como JSP e JSF. Em aplicações JavaServer Faces, mesmo os beans do tipo EJB Session Beans podem ser acessados diretamente pelas páginas, sem ter a necessidade da criação de classes Para acessar qualquer bean CDI em uma página, é necessário anotá-la o bean acessível por EL, todas demais features da especificação, como DI, 42

9 contextos, interceptors, decorators e outros, continuam existindo mesmo via EL será o mesmo nome do bean, porém iniciando com a primeira uma página JSF. Se não fosse definida a String gerenciadorrelatorio gerenciadorrelatorio ) <h:commandbutton action= #{gerenciadorrelatorio.gerarrelatorio value= Gerar Relatorio immediate= @Target(TYPE) DAO public class RelatorioDao extends BaseDao { Agrupando características de um public void salvar(relatorio relatorio){ Facilmente pode ser identificado em sistemas de 'n' camadas, tipos de objetos que apresentam características semelhantes. Geralmente essas características são associadas a responsabilidades comuns a objetos da mesma camada. Alguns exemplos disso são beans que atuam nas páginas JSF, que sempre pos- possuem seus métodos transacionais se valendo de Interceptors Bindings além de poderem conter segurança associada a sua execução, entre muitos outros exemplos. O CDI oferece em sua especificação a possibilidade de unir as características comuns dos beans, através da definição de Stereotypes. Um Stereotype pode conter vários Interceptors, um escopo padrão, nomeação para acesso via EL, a definição se o bean a qual é aplicado possui implementa- é criado um Stereotype DAO e aplicado a um bean. A especificação traz por padrão uma implementação de Stereotype chamado Model para ser utilizado em web frameworks MVC. A METHOD, FIEL) Model { Deployments alternativos O CDI permite que o desenvolvedor trabalhe com implementações alternativas de seus beans, podendo selecionar as versões apropriadas no momento de deployment. Isso pode ser útil em ambientes de desenvolvimento nos quais nem todos os recursos podem estar disponíveis ao sistema, como integração a serviços de terceiros, ou mesmo para realizar tarefas associadas a testes. Para construir uma versão alternativa de um objeto, você deve: estender a implementação original do bean, sobreescrever os métodos a serem reim- Porém, se o bean a ser substituído no deployment da aplicação possuir instância do bean em todo o sistema. Isso acontece porque um bean alternativo não herda todos os metadados de sua classe pai. Para que um segundo bean substitua completamente outro bean, além de estendê-lo ele tem que possuir suas anotações. Uma maneira simples de fazer isso é através da ano- pai. Outro ponto que pode ser incômodo na definição de Alternatives, é a declaração de cada um em beans.xml. Esta tarefa pode ser simplificada com a criação de Stereotypes, assim pode-se habilitar ou desabilitar um grupo que utiliza Stereotype e Specializes. Considerações finais Como pode ser notado, as novidades são muitas e afetam diretamente o design e comportamento das aplicações como: aumento da testabilidade de sistemas ou serviços, diminuição do acoplamento entre soluções, aumento da expressividade do código, simplificação da comunicação entre componentes da plataforma JavaEE, diminuição de problemas em runtime através da Typesafe Resolution etc. De modo geral, da persistência à apresentação, toda a plataforma JEE 6 é afetada diretamente por esta especificação. Cada um dos tópicos da especificação apresentados neste artigo podem ser explorados com mais profundidade pelo desenvolvedor que deseja trabalhar com cobrindo todos os aspectos da tecnologia. Além desta leitura, recomendo o download da implementação de referência Weld, que possui aplicações-exemplos que podem ser utilizadas como ponto de partida para um projeto CDI. Ainda sobre Weld, sua documentação é bem completa e pode ser uma excelente fonte de consulta para o desenvolvedor. Alguns Maven Archetypes para iniciar um 43

10 @Alternative public class RelatorioServiceMock extends RelatorioService System.out.println( Sendo executado RelatorioService alternativo, + nenhum relatorio sendo gerado ) beans.xml <beans xmlns= xmlns:xsi= w3.org/2001/xmlschema-instance xsi:schemalocation= com/xml/ns/javaee > <alternatives> <class>br.com.mundoj.cdiapp.relatorioservicemock</class> <class>br.com.mundoj.cdiapp. servicemock</class> <class>br.com.mundoj.cdiapp.contaswebservicemock</class>... @Target(TYPE) public class RelatorioServiceMock extends RelatorioService System.out.println( Sendo executado RelatorioService alternativo, + nenhum relatorio sendo gerado ) beans.xml <beans xmlns= xmlns:xsi= w3.org/2001/xmlschema-instance xsi:schemalocation= com/xml/ns/javaee > <!-- somente e necessario indicar o stereotype, nao as classes --> <alternatives> <class>br.com.mundoj.cdiapp.mock</class> </alternatives> </beans> Da costura a solda do Seam ao Weld Alguns frameworks se destacaram na comunidade Java na implementação de DI como, por exemplo: PicoContainer picocontainer.org/, Spring Google Guice entre outros. Com a grande aceitação destes frameworks e do emprego de injeção de dependência, o JCP resolveu incorporar no JavaEE 5 estas mesmas ideias em seu modelo de componentes gerenciados por um servidor de aplicação (Servlets, EJBs, JSF Managed Beans, DataSources etc.). Desta forma, através da especificação, ficou possível injetar qualquer componente gerenciado, em outro componente gerenciado através de anotações. Embora tenha sido um grande avanço na especificação, isso ainda não solucionava o problema de quem trabalha com classes simples, POJOs, que não eram EJBs, e ainda assim precisavam de um recurso como injeção de dependência. Estes desenvolvedores teriam que recorrer a frameworks de terceiros para obter essa funcionalidade. Outro agravante é que mesmo utilizando estes frameworks, a integração entre seus POJOs e modelos de componentes JavaEE 5 não eram possíveis de se beneficiarem mutuamente de injeção de dependência, ou seja, não era possível injetar um componente EJB em uma classe simples e vice-versa de maneira natural. Visto este gap entre a especificação e aplicações do dia-a-dia desenvolvidas por milhares de pessoas, Gavin King, criador do popular Hibernate e desenvolvedor na JBoss, divisão da Red Hat, começou o desenvolvimento de um framework onde os seus componentes pudessem interagir tanto com componentes gerenciados pelo contêiner (como, por exemplo, os EJBs), quanto componentes de classes java convencionais. Além disso, tal framework também integraria qualquer um de seus componentes (sejam POJOs simples ou não) com o modelo padrão da especificação para desenvolvimento de aplicações web, o JavaServer Faces, dispensando a criação e declaração de JSF Managed Beans. A este framework, Gavin King lhe deu o nome de Seam, que significa costura que é justamente o que o framework se propõe a fazer integrando os mais diversos aspectos da especificação com facilidades necessárias para o desenvolvimento de softwares em Java. relacionado à DI para quase todos tipos de objeto, assim como ser pioneiro na ideia de modelagem de instâncias contextuais. No mesmo mês da liberação do Seam, Gavin King alavanca uma nova JSR junto ao JCP a fim de trazer os benefícios do framework para a especificação JavaEE. A requisição de Gavin foi catalogada mudanças até sua versão final hoje chamada oficialmente de Contexts and Dependency Injection for the JavaTM EE platform, o que de fato faz mais sentido uma vez que é possível a utilização de seus componentes mesmo sem a aplicação interagir com a web. Em paralelo a sua aprovação no JCP, a JBoss trabalhou em 44

11 "SUJHP t $%* o *OKFÎÍP EF %FQFOEÐODJB F (FSFODJBNFOUP EF $POUFYUPT OP +BWB && uma implementação para a especificação, também iniciada sobre o nome WebBeans, mas hoje chamada de Weld (solda). Após uma série de discussões sobre possíveis conflitos entre a +43 $%* F B +43 %* WFS NBJT EFUBMIFT TPCSF B +43 OP RVBESP i3fmbîíp FOUSF B +43 F +43 w B FTQFDJmDBÎÍP GPJ aprovada e hoje é parte integrante da plataforma JavaEE 6. Weld, por sua vez, é a implementação de referência desta especificação. Além de implementar o CDI como um todo, Weld também traz extensões portáveis construídas sob a SPI da especificação, como suporte a Wicket para estrutura MVC web, possibilidade de executar em ambientes JavaSE puros como aplicações Desktop, assim como em simples containers servlets. Pelo fato do Weld implementar várias ideias presentes no Seam Framework, e ambos serem mantidos pelo time JBoss da Red Hat, alguns desenvolvedores podem estar em dúvida sobre a continuidade ou futuro dos projetos, mas o fato é que os dois projetos coexistirão. Seam 3 irá possuir como mecanismo de DI e gerenciamento de contextos o Weld, porém manterá seus aspectos de integração com as ferramentas não-standards da plataforma JavaEE, como geração de PDFs, geração de planilhas, escopo baseado em jbpm, Identity Management, envio de via facelet, integração com GWT, integração com Drools, apoio de ferramentas de desenvolvimento (seam-gen, jboss tools), integração com Hibernate, componentes JSFs customizados e qualquer outra adição não-padrão da plataforma. Para migração do Seam e seu mecanismo atual de DI e componenuft DPOUFYUVBJT 4FBN Y QBSB B OPWB JNQMFNFOUBÎÍP CBTFBEB no Weld e suas anotações (Seam 3.x), existe um projeto chamado Seam Bridge que permitirá a utilização de beans CDI juntamente com o antigo modelo de componentes do framework, garantindo a portabilidade entre as soluções. Referências t +43 $%* IUUQ KDQ PSH FO KTS EFUBJM JE t +43 %* IUUQ KDQ PSH FO KTS EFUBJM JE t +43 WFSTVT +43 IUUQ SFMBUJPO UP #MPHHFST CommentsOnAnnotationsForDependencyInjection t $%* 3FGDBSE IUUQ SFGDBSE[ E[POF DPN SFGDBSE[ DPOUFYUT BOE EFQFODFODZ t 8FME P $%* 3* IUUQ TFBNGSBNFXPSL PSH 8FME t 8FME o.bwfo "SDIFUZQFT IUUQ TFBNGSBNFXPSL PSH %PDVNFOUBUJPO 8FME2VJDLTUBSU'PS.BWFO6TFST t 4FBN 'SBNFXPSL IUUQ TFBNGSBNFXPSL PSH t (PPHMF (VJDF IUUQ DPEF HPPHMF DPN Q HPPHMF HVJDF 3FMBÎÍP FOUSF B +43 F +43 " QPMÐNJDB +43 %FQFOEFODZ *OKFDUJPO GPS +BWB GPJ FTDSJUB por Bob Lee (criador do Google Guice) e Rod Johnson (criador do Spring Framework) com o propósito: Propomos esta JSR para maximizar a reutilização, testabilidade e manutenção do código Java padronizando um extensível API para injeção de dependência. A questão é que tal JSR não padroniza absolutamente nenhum aspecto comportamental ou qualquer menção de como seria o ciclo de vida em uma implementação baseada nesta especificação. Os únicos pontos realmente especificados na JSR são algumas BOPUBÎÜFT!*OKFDU!/BNFE!1SPWJEFS!2VBMJmFS!4DPQF F! Singleton. Qualquer framework que utilize essas anotações pode dizer que implementa a especificação. Isso é muito vago e não garante qualquer tipo de comportamento em aplicações que compartilhem de mesmas anotações, mas com implementações diferentes, ou seja, QPVDB DPJTB Ï QPSUÈWFM " +43 o $%* QFMP DPOUSÈSJP QPTTVJ VN comportamento bem definido para todos os aspetos referentes à DI e contextos, o que deixou muita gente no JCP sem saber a real necessidade de uma segunda especificação. A SpringSource, agora sob o nome de VmWare no JCP, se ausentou de todas as WPUBÎÜFT QBSB B +43 P RVF JNQFEJV EF BKVEBS RVF P JNQBTTF sobre a necessidade ou não desta segunda especificação fosse SFTPMWJEP $PNP USÏHVB B +43 BDBCPV QPS VUJMJ[BS BT BOPUBÎÜFT EFmOJEBT OB +43 BDBMNBOEP PT ÉOJNPT OP DPNJUÐ $PN tudo, a controvérsia sobre as duas especificações ainda é motivo de grande discussão. Empresas como IBM, Red Hat e Sun fizeram TFWFSBT DSÓUJDBT F PCTFSWBÎÜFT OPT WPUPT QBSB +43 F +43 Para o leitor poder saber sobre o impacto das divergências entre BT EVBT FTQFDJmDBÎÜFT VN FYFNQMP B!/BNFE QBSB +43 TPbretudo, define uma nomeação para um bean ser acessado por EL em uma página JSP ou JSF (leia neste artigo a sessão Acessando CFBOT FN QÈHJOBT XFCw 1BSB B +43!/BNFE EJ[ BQFOBT TF tratar de um critério para injetar um objeto em outro baseado em VNB 4USJOH DPNP i!*okfdu!/bnfe QBTTFOHFS 4FBU QBTTFOHFS4FBU w "HPSB VNB QFSHVOUB TF P EFTFOWPMWFEPS TJNQMFTNFOUF FODPOUSBS VNB DMBTTF BOPUBEB DPN!/BNFE TFSÈ RVF FMF QPEF acessar diretamente aquela classe de uma página? A resposta será: depende de quem implementa a anotação se for o Weld RVF TFHVF B +43 QPEF NBT TF OÍP GPS 45