Injeção de Dependência e Gerenciamento de Contextos no Java EE 6
Propaganda
artigo CDI Injeção de Dependência e Gerenciamento de Contextos no Java EE 6 Alessandro Lazarotti ([email protected]) 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), (http://martinfowler.com/articles/injection. 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 0SFTQPOTÈWFMQPSFTUBOPWJEBEFÏB+43i$POUFYUTBOE%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 1FSNJUJSRVFRVBMRVFSVNEFTFVTPCKFUPTHFSFODJBEPTTFKBNBDFTsíveis diretamente por uma interface JSF ou JSP através de Unified Expression Language (EL). t 0GFSFDFSOPWPNFDBOJTNPEFEFDMBSBÎÍPEFJOUFSDFQUBEPSFTGSBDBmente acoplados. t )BCJMJEBEFEFiEFDPSBSwPCKFUPTJOKFUBEPT t 6NNPEFMPEFOPUJmDBÎÍPEFFWFOUPT t 6NOPWPDPOUFYUPXFCTPNBOEPBP3FRVFTU"QQMJDBUJPOF4FTsion, chamado de Conversation. t 'PSOFDFSVNDPOKVOUPEF41*4FSWJDF1SPWJEFS*OUFSGBDFQBSBQPTsibilitar 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 "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& 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: t 4FKBDPODSFUBPVBOPUBEBDPN!%FDPSBUPS t 5FOIB QFMP NFOPT VN DPOTUSVUPS TFN QBSÉNFUSP PV BOPUBEP DPN!*OKFDU t /ÍPTFKBVN&+# t /ÍPTFKBVNB+1"&OUJUZ t /ÍPTFKBVNBDMBTTFJOUFSOB t /ÍPJNQMFNFOUFBJOUFSGBDFKBWBYFOUFSQSJTFJOKFDUTQJ&YUFOTJPO 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, DPNP !QPTU$POTUSVDU JOWPDBEP BQØT JOJDJBMJ[BS P CFBO F!1SF%FTUSPZ (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 RVBMRVFSUJQPEFJOKFÎÍPEFSFDVSTPTDPNP!1FSTJTUFODF$POUFYU!3FTPVSDF !&+#FEFNBJTBOPUBÎÜFTQBSB%*EFDPNQPOFOUFT+BWB&&FNTFVTBUSJCVUPT 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. Dependency Injection 0 $%* USBCBMIB DPN %* BUSBWÏT EF BOPUBÎÜFT EFmOJEBT QFMB +43 i%FQFOEFODZ*OKFDUJPOGPS+BWBwWFSNBJTEFUBMIFTTPCSFB+43OP RVBESPi3FMBÎÍP FOUSF B +43 F +43w 6N FYFNQMP EF DPNP Ï SFBMJ[BEBBJOKFÎÍPEFEFQFOEÐODJBDPN$%*FTUÈOB-JTUBHFN -JTUBHFN*NQMFNFOUBÎÍPTJNQMFTEFJOKFÎÍPEFEFQFOEÐODJB public class RelatorioGerencial{ ... } public class RelatorioService{ private @Inject RelatorioGerencial relatorioGerencial; public void gerarRelatorio() { // implementação } } Nesta primeira listagem, é injetado o bean RelatorioGerencial no bean 3FMBUPSJP4FSWJDFBUSBWÏTEBBOPUBÎÍP!*OKFDU*NQPSUBOUFOPUBSRVFOÍP 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 -JTUBHFNPÞOJDPCFBORVFDPSSFTQPOEFBPUJQP3FMBUPSJP(FSFODJBMGPJ injetado. Isso é diferente de frameworks como o JBoss Seam até sua verTÍPYOBRVBMBJOKFÎÍPÏCBTFBEBFN4USJOHTPVOPOPNFEBWBSJÈWFM BRVBMFTUÈTFOEPSFBMJ[BEBBJOKFÎÍP"-JTUBHFNUSB[PVUSPFYFNQMP também válido para injetar RelatorioGerencial em RelatorioService. -JTUBHFN%*CBTFBEBOBJOUFSGBDF public class RelatorioGerencial implements Relatorio { ... } public class RelatorioService{ Session Beans private @Inject Relatorio relatorio; Session Beans são componentes gerenciados pelo servidor de aplicação definidos pela especificação Enterprise JavaBeans (ver nesta edição o artigo mais HFSBMTPCSF+BWB&&PVOBFEJÎÍPPBSUJHPTPCSF&+# MPHPRVFNEFmOF 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. public void gerarRelatorio(){ 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. 36 www.mundoj.com.br // implementação } } 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, QFMBQSØQSJBQMBUBGPSNB+BWB C 3FMBUPSJPFD 3FMBUPSJP(FSFODJBM "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& 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 EBBOPUBÎÍP!5ZQFE7FKBB-JTUBHFN Listagem 3. Restringindo o bean ao tipo RelatorioGerencial. @Typed(RelatorioGerencial.class) public class RelatorioGerencial implements Relatorio { ... } 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 RelatorioGerencial, como é declarado na Listagem 3, não poderia ser injetado em 3FMBUPSJP4FSWJDFEB-JTUBHFNQPJTJTTPSFTVMUBSJBFNVNFSSPFNUFNQP de deployment. Resolvendo ambiguidades com @Qualifers 4FPCFBOOÍPQPTTVJSFTUSJÎÜFTEFUJQPDMBTTFBOPUBEBDPN!5ZQFE F 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 implements Relatorio { ... } public class RelatorioFuncional implements Relatorio{ ... } 2VBM EFTUFT CFBOT TFSJB JOKFUBEP FN 3FMBUPSJP4FSWJDF EB -JTUBHFN RVF 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ÎÍPEF!2VBMJmFS0DØEJHPEB-JTUBHFNFYJCFDPNPDPOTUSVJSVNBBOPUBÎÍP 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 QPTTVJ TPCSF TJ VNB BOPUBÎÍP EP UJQP 2VBMJmFS DPNP P !(FSFODJBM FN 3FMBUPSJP(FSFODJBMEB-JTUBHFNQPTTVJJNQMJDJUBNFOUFVN2VBMJmFS! %FGBVMU4FNQSFRVFÏVUJMJ[BEP!*OKFDUFMFQSPDVSBBVUPNBUJDBNFOUFVN UJQPEBRVFMFCFBODPNPRVBMJmDBEPS!%FGBVMUTFWPDÐOÍPEFmOJSFYQMJDJUBNFOUFPVUSPWFS-JTUBHFN -JTUBHFN6UJMJ[BÎÍPEF!2VBMJmFS /* * Criando anotação Gerencial, do tipo Qualifier */ @Qualifier @Retention(RUNTIME) public @interface Gerencial {} /* * Criando anotação Funcional, do tipo Qualifier */ @Qualifier @Retention(RUNTIME) public @interface Funcional{} /* * Definindo um bean como Gerencial */ @Gerencial public class RelatorioGerencial implements Relatorio { ... } /* * Definindo um bean como Funcional */ @Funcional public class RelatorioFuncional implements Relatorio { ... } /* * Resolvendo ambiguidade */ public class RelatorioService{ private @Inject @Gerencial Relatorio relatorio; public void gerarRelatorio(){ // implementação } } 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 "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& WMFU3FRVFTU-JTUFOFSPV"TZOD-JTUFOFSEVSBOUFJOWPDBÎÜFTEFRVBMRVFS +&&8FC4FSWJDFTEVSBOUFJOWPDBÎÜFTSFNPUBTBRVBMRVFS&+#EVSBOUF BFYFDVÎÍPEFVNNÏUPEPEFUJNFPVUEF&+#5JNFSTEVSBOUFBFOUSFHB 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. !4FTTJPO4DPQFE DPOUFYUP BUJWP B QBSUJS EF VNB TPMJDJUBÎÍP BP método“service()” de qualquer Servlet ou “doFilter()” de qualquer servlet 'JMUFSRVBOEPPDPOUBJOFSFYFDVUB)UUQ4FTTJPO-JTUFOFS4FSWMFU3FRVFTtListener 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(). !"QQMJDBUJPO4DPQFEÏDSJBEPQPSRVBMRVFSTFSWMFUSFRVFTUJOWPDBÎÜFT 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. !$POWFSTBUJPO4DPQFEFTUFDPOUFYUPÏEFmOJEPJOJDJBMNFOUFQBSBRVBMquer 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 demarcações. Listagem 6. Tipos de injeção. private @Inject Relatorio relatorio; ... //injeção por método set @Inject public void setRelatorio(Relatorio relatorio) { t this.relatorio = relatorio; } ... //injeção por construtor @Inject public RelatorioService(Relatorio relatorio) { t this.relatorio = relatorio; } //injeção por construtor usando qualifiers @Inject public RelatorioService(@Gerencial Relatorio relatorioGerencial, @Funcional Relatorio relatorioFuncional) { t 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 8. Bean no escopo Conversation. @ConversationScoped @Stateful public class RelatorioService{ private @Inject @Gerencial Relatorio relatorio; private @Inject Conversation conversation; // outros atributos Listagem 7. Bean no escopo de sessão. @SessionScoped public class RelatorioService{ public void gerarRelatorio( .. ){ conversation.begin(); // implementação } private @Inject @Gerencial Relatorio relatorio; public void gerarRelatorio(){ // implementação } public void downloadRelatorio( .. ){ // implementação conversation.end(); } } 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: t !3FRVFTU4DPQFEDPOUFYUPBUJWPBQBSUJSEFVNBSFRVJTJÎÍPQPEFOEP ser ela: invocações ao método“service()” de qualquer Servlet ou “doFilUFS wEFRVBMRVFSTFSWMFU'JMUFSRVBOEPPDPOUBJOFSFYFDVUBBMHVN4FS38 www.mundoj.com.br @Remove public void destroy() {} } "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& 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 JNQMJDJUBNFOUFPNÏUPEPEFTUSPZ BOPUBEPDPN!3FNPWFEFTUSVJOEPEFmnitivamente 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. Produzindo Beans -JTUBHFN$SJBOEPCFBOTDPN!1SPEVDFT public @SessionScoped class Configuracao { private TipoDeRelatorio tipoDeRelatorio; ... public @Produces @Configurado Relatorio obtemRelatorio(){ switch (tipoDeRelatorio) { case GERENCIAL: return new RelatorioGerencial(); Embora um Session Bean seja utilizado nesta listagem, também poderia ser VN.BOBHFE#FBO/FTUFDBTPOÍPQSFDJTBSJBFYJTUJSVNNÏUPEPDPN!3FNPve (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. case FUNCIONAL: return new RelatorioFuncional(); default: return null; } } } @RequestScoped public class RelatorioService{ private @Inject @Configurado Relatorio relatorio; 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 chaNBEPQTFVEPFTDPQP!%FQFOEFOU6NCFBOEFTUFUJQPQPTTVJTFVDPOUFYUPF ciclo de vida dependente do escopo do objeto a qual ele é injetado, quando VNÏDSJBEPPPVUSPUBNCÏNÏ/B-JTUBHFNUFOEPFNWJTUBPTUJQPTQBESÜFT do CDI, é correto afirmar que um objeto do tipo RelatorioGerencial é um manaHFECFBODPNRVBMJmFS!%FGBVMUFQTFVEPFTDPQP!%FQFOEFOU 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 da anotação !/FX7FKBVNFYFNQMPEFDPNPJTTPQPEFTFSGFJUPOB-JTUBHFN public void gerarRelatorios(){ // implementação } } -JTUBHFN6TPEF!1SPEVDFTDPN%*OPTQBSÉNFUSPT public @SessionScoped class Configuracao { private TipoDeRelatorio tipoDeRelatorio; ... public @Produces @Configurado Relatorio obtemRelatorio( RelatorioGerencial gerencial, RelatorioFuncional funcional){ switch (tipoDeRelatorio) { -JTUBHFN6UJMJ[BOEPQTFVEPFTDPQPBUSBWÏTEF!/FX @Gerencial @SessionScoped public class RelatorioGerencial implements Relatorio { ... } case GERENCIAL: return gerencial; case FUNCIONAL: return funcional; default: return null; @RequestScoped public class RelatorioService{ } private @Inject @Gerencial Relatorio relatorio; private @Inject @New @Gerencial Relatorio novoRelatorio; public void gerarRelatorios(){ // implementação } } /B -JTUBHFN B DMBTTF 3FMBUPSJP4FSWJDF QPTTVJ EPJT CFBOT EP UJQP 3FlatorioGerencial, um no contexto session e outro (novoRelatorio) no contexto request, por possuir escopo dependente. } } 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 conUFYUVBJTEP$%*BUSBWÏTEBBOPUBÎÍP!1SPEVDFT"MÏNEFQSPNPWFSWBSJBEPT UJQPTEFPCKFUPTBTFSCFBOT!1SPEVDFTUBNCÏNQPEFTFSVUJMJ[BEPDPNPVNB 39 "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& ferramenta poderosa de polimorfismo, mudando o comportamento de sua BQMJDBÎÍPFNUFNQPEFFYFDVÎÍP7FKBVNFYFNQMPOB-JTUBHFN "BOPUBÎÍP!$POmHVSBEPEB-JTUBHFNÏEPUJQP2VBMJmFSBTTJNDPNP! (FSFODJBMF!'VODJPOBMEB-JTUBHFN&TUF2VBMJmFSÏVUJMJ[BEPQBSBSFTPMWFSB !*OKFDUFN3FMBUPSJP4FSWJDFVUJMJ[BOEPPNÏUPEP1SPEVDFTPCUFN3FMBUPSJP 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 JNQMÓDJUBOPTNÏUPEPTDPN!1SPEVDFT7FKBPNFTNPNÏUPEPPCUFN3FMBUPSJP EB-JTUBHFNNPEJmDBEPQBSBVTPEFJOKFÎÍPJNQMÓDJUBOB-JTUBHFN Outra forma de expor rapidamente um objeto como managed bean, é BUSBWÏTEFBUSJCVUPTBOPUBEPTDPN!1SPEVDFT0FGFJUPÏPNFTNPEP RVFOPTNÏUPEPT"-JTUBHFNUSB[VNB4USJOHFTUÈUJDBTFOEPQSPNPWJEBBCFBO$%*FNFTDPQP"QQMJDBUJPOBUSBWÏTEF!1SPEVDFT 0SFTQPOTÈWFMQPSJOKFUBSVNCFBOBTFSEFTUSVÓEPÏBBOPUBÎÍP!%JTQPTFT" DMBTTFRVFDPOUÏNVN!1SPEVDFTRVFQSPEV[EFUFSNJOBEP#FBOQPEFQPTTVJS NÏUPEPTDPNQFMPNFOPTVNEFTFVTBSHVNFOUPTDPNBBOPUBÎÍP!%JTQPTFT BmNEFFODFSSBSSFDVSTPTDPNPFTUÈSFQSFTFOUBEPOB-JTUBHFN Nesta listagem, o método encerrar é chamado automaticamente pelo CDI quando a conversação associada ao bean EntityManager com qualimFS!3FMBUPSJP%BUB#BTFGPSFODFSSBEB*TTPPDPSSFQPSDPOUBEBBOPUBÎÍP !%JTQPTFTFNVNEFTFVTBSHVNFOUPT 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 exemplo EFVNJOUFSDFQUPSEP+BWB&&OB-JTUBHFN -JTUBHFN6TPEF!1SPEVDFTFNBUSJCVUPT -JTUBHFN6UJMJ[BÎÍPEFJOUFSDFQUPSTFN$%* public @SessionScoped class Configuracao { private @Produces @ApplicationScopped @Desenvolvedor static String dev = “Lazarotti”; public class LoggerInterceptor { Logger logger = ... ... @AroundInvoke public Object logar(InvocationContext context) { logger.debug(“ Executando o metodo “+ context.getMethod()); return context.proceed(); } Destruindo Beans } } -JTUBHFN'JOBMJ[BOEPBQSPQSJBEBNFOUFCFBOTDPN!%JTQPTFT public class RelatorioEntityManager { @PersistenceUnit(unitName=”RelatorioDataBase”) EntityManagerFactory emf; @Stateless @Interceptors(LoggerInterceptor.class) public class RelatorioService { ... @Produces @ConversationScoped @RelatorioDataBase public EntityManager criar() { public void gerarRelatorios(){ // implementação } return emf.createEntityManager(); } } public void encerrar(@Disposes @RelatorioDataBase 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 QPS!1SPEVDFTQPEFNPTEFmOJSVNPVNBJTNÏUPEPTQBSBTFSFYFDVUBEPOP momento em que o bean é destruído, assim recursos alocados na criação da instância podem ser encerrados de maneira correta nestes. 40 www.mundoj.com.br 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 TJNQMFTQBSBIBCJMJUBSPVOÍPPVTPEPTNFTNPT"-JTUBHFNUSB[PNFTNP DØEJHPEB-JTUBHFNQPSÏNVUJMJ[BOEP*OUFSDFQUPS#JOEJOHT 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. YNMDPOGPSNF-JTUBHFN "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& 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. -JTUBHFN6UJMJ[BÎÍPEFJOUFSDFQUPSDPN$%* /* * Criando anotação Logged, do tipo InterceptorBinding */ @InterceptorBinding @Retention(RUNTIME) public @interface Logged{} 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 os UFSNPTEBFTQFDJmDBÎÍPWBNPTWFSPFYFNQMPEB-JTUBHFN -JTUBHFN6UJMJ[BÎÍPEF%FDPSBUPST public class RelatorioService { private @Inject Relatorio relatorio; public void gerarRelatorios(){ // implementação } public @Interceptor @Logged class LoggerInterceptor { Logger logger = ... @AroundInvoke public Object logar(InvocationContext context) { logger.debug(“ Executando o metodo ”+ context.getMethod()); return context.proceed(); } } @Decorator public class RelatorioServiceDecorator { private @Inject @Delegate RelatorioService relatorioService; private @Inject Emailservice correio; } public void gerarRelatorios(){ 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(); } @Stateless @Logged public class RelatorioService { ... public void gerarRelatorios(){ // implementação } } } -JTUBHFN)BCJMJUBOEP*OUFSDFQUPS#JOEJOHTFNCFBOTYNM <beans xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun. 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 Neste exemplo, RelatorioService está sendo decorado por RelatorioService%FDPSBUPSBOPUBEPDPN!%FDPSBUPS$BTPBTPMJDJUBÎÍPQBSBHFSBÎÍPEFVN 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 *OKFDUJPO1PJOUOPTTPPCKFUPBMWP/PDBTPEB-JTUBHFNBBOPUBÎÍP! Delegate em RelatorioService, define que ele é o bean a ser interceptado. 4ØQPEFFYJTUJSVNÞOJDPBUSJCVUPJOKFUBEPDPNBEFNBSDBÎÍP!%FMFHBUF em um Decorator. Um Decorator deve ter a assinatura de método idêntica ao método que se deTFKBSiEFDPSBSwBTTJNDPNPÏNPTUSBEPOB-JTUBHFN1BSBUBMVN%FDPSBUPS 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 EFDPSBEPJODMVTJWFTFSEFTDPOUJOVBEBTVBFYFDVÎÍP"JOEBOB-JTUBHFN 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 "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& 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. YNMQBSBTFSFNIBCJMJUBEPT7FKBOB-JTUBHFNDPNPJTTPÏGFJUP -JTUBHFN)BCJMJUBOEP%FDPSBUPSTFNCFBOTYNM -JTUBHFN6UJMJ[BOEPFWFOUPT @Qualifier @Target({FIELD, PARAMETER}) @Retention(RUNTIME) public @interface Pronto { } public class RepositorioDeRelatorios { public void adicionar(@Observes @Pronto Relatorio relatorio){ ... } <beans xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun. 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 GBÎBBMHVNTFOUJEP"-JTUBHFNFYFNQMJmDBFTUFUJQPEFEFQFOEÐODJB } @Stateless @Remote(Email.class) public class EmailService implements Email{ @Asynchronous public void mensagemParaRelatorios(@Observes @Pronto Relatorio relatorio){ enviar(“O relatorio requisitado esta concluído e disponível no ftp”) .para(relatorio.getUsuario().getEmail()); } } public class RelatorioService { private @Inject Relatorio relatorio; @Inject @Pronto Event<Relatorio> relatorioEvent; public void gerarRelatorio(){ // implementação ... relatorioEvent.fire(relatorio); } -JTUBHFN$PNQPTJÎÍPQBSBBQSPWFJUBNFOUPEFTFSWJÎPT public class RelatorioService { } private @Inject Relatorio relatorio; private @Inject RepositorioDeRelatorios repositorio; private @Inject Email correio; public void gerarRelatorio(){ // implementação ... repositorio.adicionar(relatorio); correio.enviarMesagem(“O relatorio requisitado esta concluído e disponível no ftp”) 6NBOPWBDPOEJÎÍPQBSBPFTUBEPEFVNSFMBUØSJPGPJEFmOJEBQFMPRVBMJmFS! Pronto. Tanto RepositorioDeRelatorios como EmailService possuem observadores de eventos, para quando um relatório atingir o estado de pronto realizar BMHVNBBÎÍP*TTPÏGFJUPBUSBWÏTEBBOPUBÎÍP!0CTFSWFTFNTFVTNÏUPEPT 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 OB-JTUBHFNBDMBTTF3FMBUPSJP4FSWJDF "JOUFSGBDF&WFOUQPTTVJPNÏUPEP fire(Event) que de fato irá disparar o evento. .para(relatorio.getUsuario().getEmail()); } Acessando beans em páginas web } 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 e-mail notificando o usuário que seu relatório está disponível. Porém, para alguns arquitetos, a dependência do bean RepositorioDeRelatorios e Email 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. A Listagem FYJCFBNFTNBTPMVÎÍPVUJMJ[BOEPFWFOUPT 42 www.mundoj.com.br É 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 +BWB JOUFSNFEJÈSJBT BOPUBEBT DPN !.BOBHFE#FBOT PV EFDMBSBEBT OP BSRVJWPGBDFTDPOmHYNMWFSOFTUBFEJÎÍPBSUJHPTPCSF+4' Para acessar qualquer bean CDI em uma página, é necessário anotá-la DPN!/BNFE$POUVEPFTTBBOPUBÎÍPOÍPUFNPNFTNPFGFJUPRVFB TFNFMIBOUF!/BNFEPGSBNFXPSL+#PTT4FBNSFTQPOTÈWFMQPSUPSOBS VNBDMBTTFRVBMRVFSFNVNDPNQPOFOUF4FBN /P$%*!/BNFEUPSOB o bean acessível por EL, todas demais features da especificação, como DI, "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& contextos, interceptors, decorators e outros, continuam existindo mesmo TFNUBMBOPUBÎÍP4FOFOIVNOPNFGPSBEJDJPOBEPB!/BNFEPOPNF via EL será o mesmo nome do bean, porém iniciando com a primeira MFUSB FN NJOÞTDVMB /B -JTUBHFN 3FMBUPSJP4FSWJDF Ï FYQPTUP QBSB uma página JSF. Se não fosse definida a String “gerenciadorRelatorio” na BOPUBÎÍPNBJTBJOEBTJNBDMBTTFGPTTFBOPUBEBDPN!/BNFEPBDFTTP OBQÈHJOBTFSJBBUSBWÏTEF\SFMBUPSJP4FSWJDFHFSBS3FMBUPSJP^ -JTUBHFN/PNFBOEPVNCFBOQBSBBDFTTP&@Named(“gerenciadorRelatorio”) public class RelatorioService { private @Inject Relatorio relatorio; public void gerarRelatorio(){ // implementação } } <h:commandButton action=”#{gerenciadorRelatorio.gerarRelatorio}” value=”Gerar Relatorio” immediate=”true”/> Agrupando características de um bean -JTUBHFN$SJBOEPVN4UFSFPUZQF @ConversationScoped @Transactional @Logged @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface DAO {} @DAO public class RelatorioDao extends BaseDao { @Override public void salvar(Relatorio relatorio){ // implementação } } 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 posTVFN!/BNFEQBSBFTUBSEJTQPOÓWFJTFNQÈHJOBTFOBTVBNBJPSJBFTUÍPOP FTDPQP!3FRVFTU4DPQFE#FBOTRVFJOUFSBHFNDPNBDBNBEBEFQFSTJTUÐODJB 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ÎÍPBMUFSOBUJWBFBJOEBUFSVNDPOKVOUPEFPVUSPT4UFSFPUZQFT/B-JTUBHFN é 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 forma como GPJDPOTUSVÓEPFTVBTDBSBDUFSÓTUJDBTFTUÍPOB-JTUBHFN -JTUBHFN04UFSFPUZQF.PEFM @Named @RequestScoped @Stereotype @Target({TYPE, METHOD, FIEL}) @Retention(RUNTIME) public @interface 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 reimQMFNFOUBEPTBOPUBSBDMBTTFDPN!"MUFSOBUJWFFIBCJMJUBSFTTBWFSTÍPFN CFBOTYNM"-JTUBHFNFYFNQMJmDBFTUFTQBTTPT Porém, se o bean a ser substituído no deployment da aplicação possuir RVBMJmFST BQFOBT B BOPUBÎÍP !"MUFSOBUJWF OÍP JSÈ DPOTFHVJS TVCTUJUVJS B 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 anoUBÎÍP!4QFDJBMJ[FTRVFUSB[QBSBBDMBTTFmMIBUPEPTPTRVBMJmFSTEBDMBTTF 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 JOUFJSPEFCFBOTBMUFSOBUJWPT"-JTUBHFNFYJCFBVUJMJ[BÎÍPEFVNCFBO 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 $%*"MFJUVSBEBFTQFDJmDBÎÍP+43ÏTJNQMFTFDPNQPTUBEFWÈSJPTDØEJHPT 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 QSPKFUP$%*DPNP8FMEKÈFTUÍPEJTQPOÓWFJTWFKBSFGFSÐODJBT t 43 "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+BWB&& -JTUBHFN*NQMFNFOUBÎÍPBMUFSOBUJWBEFVNCFBO Da costura a solda – do Seam ao Weld @Alternative public class RelatorioServiceMock extends RelatorioService { @Override public void gerarRelatorio(){ System.out.println(“Sendo executado RelatorioService alternativo, “ + “nenhum relatorio sendo gerado”) } } beans.xml <beans xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:xsi=”http://www. w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun. com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd”> <alternatives> <class>br.com.mundoj.cdiapp.RelatorioServiceMock</class> <class>br.com.mundoj.cdiapp.EmailServiceMock</class> <class>br.com.mundoj.cdiapp.ContasWebserviceMock</class> ... </alternatives> </beans> -JTUBHFN#FBOBMUFSOBUJWPDPN4UFSFPUZQFF4QFDJBMJ[FT @Alternative @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Mock {} @Specializes @Mock public class RelatorioServiceMock extends RelatorioService { @Override public void gerarRelatorio(){ System.out.println(“Sendo executado RelatorioService alternativo, “ + “nenhum relatorio sendo gerado”) } } beans.xml <beans xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:xsi=”http://www. w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun. com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd”> <!-- somente e necessario indicar o stereotype, nao as classes --> <alternatives> <class>br.com.mundoj.cdiapp.Mock</class> </alternatives> </beans> 44 www.mundoj.com.br Alguns frameworks se destacaram na comunidade Java na implementação de DI como, por exemplo: PicoContainer http://www. picocontainer.org/, Spring http://www.springsource.org/about, Google Guice http://code.google.com/p/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. 'PJEJTQPOJCJMJ[BEPQBSBEPXOMPBEBWFSTÍPEP4FBNFNKVOIP EF 0 4FBN USB[JB DPOTJHP BT GBDJMJEBEFT FN UPEP BTQFDUP 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 DPNP +43 DPN P OPNF EF 8FC#FBOT IUUQKDQPSHFO KTSTVNNBSZ JE 0 OPNF EB FTQFDJmDBÎÍP UFWF BMHVNBT 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 "SUJHPt$%*o*OKFÎÍPEF%FQFOEÐODJBF(FSFODJBNFOUPEF$POUFYUPTOP+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$%*FB+43%*WFSNBJTEFUBMIFTTPCSFB+43OP RVBESPi3FMBÎÍPFOUSFB+43F+43w BFTQFDJmDBÎÍPGPJ 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 e-mail 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$%*IUUQKDQPSHFOKTSEFUBJM JE t +43%*IUUQKDQPSHFOKTSEFUBJM JE t +43 WFSTVT +43 IUUQSFMBUJPOUP#MPHHFST CommentsOnAnnotationsForDependencyInjection t $%*3FGDBSEIUUQSFGDBSE[E[POFDPNSFGDBSE[DPOUFYUTBOEEFQFODFODZ t 8FMEP$%*3*IUUQTFBNGSBNFXPSLPSH8FME t 8FME o .BWFO "SDIFUZQFT IUUQTFBNGSBNFXPSLPSH%PDVNFOUBUJPO 8FME2VJDLTUBSU'PS.BWFO6TFST t 4FBN'SBNFXPSLIUUQTFBNGSBNFXPSLPSH t (PPHMF(VJDFIUUQDPEFHPPHMFDPNQHPPHMFHVJDF 3FMBÎÍPFOUSFB+43F+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!4DPQFF! 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, QPVDBDPJTBÏQPSUÈWFM"+43o$%*QFMPDPOUSÈSJPQPTTVJVN 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ÎÜFTQBSBB+43PRVFJNQFEJVEFBKVEBSRVFPJNQBTTF sobre a necessidade ou não desta segunda especificação fosse SFTPMWJEP $PNP USÏHVB B +43 BDBCPV QPS VUJMJ[BS BT BOPUBÎÜFTEFmOJEBTOB+43BDBMNBOEPPTÉOJNPTOPDPNJUÐ$PN tudo, a controvérsia sobre as duas especificações ainda é motivo de grande discussão. Empresas como IBM, Red Hat e Sun fizeram TFWFSBTDSÓUJDBTFPCTFSWBÎÜFTOPTWPUPTQBSB+43F+43 Para o leitor poder saber sobre o impacto das divergências entre BTEVBTFTQFDJmDBÎÜFTVNFYFNQMPB!/BNFEQBSB+43TPbretudo, 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 CFBOTFNQÈHJOBTXFCw 1BSBB+43!/BNFEEJ[BQFOBTTF tratar de um critério para injetar um objeto em outro baseado em VNB 4USJOH DPNPi!*OKFDU !/BNFEQBTTFOHFS 4FBU QBTTFOHFS4FBUw"HPSBVNBQFSHVOUBTFPEFTFOWPMWFEPSTJNQMFTNFOUF FODPOUSBSVNBDMBTTFBOPUBEBDPN!/BNFETFSÈRVFFMFQPEF acessar diretamente aquela classe de uma página? A resposta será: “depende de quem implementa a anotação” – se for o Weld RVFTFHVFB+43 QPEFNBTTFOÍPGPS 45
