Web Beans morreu. Agora se chama JCDI (Java Contexts and Dependency Injection)

Já há alguns dias, Garvin King deu a notícia, junto com o public draft revisado, de que JSR-299 se chamará Java Contexts and Dependency Injection.

É uma boa coisa, pois a especificação estava cada vez menos parecida com Seam, e mais parecida com Guice versão “Enterprise”. E era nítido que a JSR-299 servia para um monte de coisas, não só pra web.

eu vejo isso de uma forma muito boa. realmente a especificacao era o guice, e super independente de jsf…

Só não espero que vire uma bola de neve toda confusa.

edit: eis o futuro do JEE / sun mode

Finalmente!
A muito tempo estava para ser definido o novo nome para a JSR-299. Mesmo quando o nome Webbeans ressoava na especificação, ja estava documentado que o componente poderia ser executado fora de um ambiente web (o que de fato não estava caindo bem para o nome).

Que venha o Seam 3 e seu novo core :twisted:

Mas o Gavin tem deixado claro nas listas que suportar os “Contextual Components” fora de containers está fora de cogitação para esta JSR.

é uma especificação que dispõe de um framework com foco em DI, como jus ao seu nome.

Tudo bem que o nome WebBeans nao era o melhor, mas porque diabos esse povo gosta de arrumar sigla complicada que começa com J??? É algum tipo de fetiche???

JNI, JSF, JNDI, JSP, JDK, JRE, JPQP…

Que nome mais desgraçado hein ?

Isso me faz lembrar aquele maldito framework de integração com browsers… JDIC

não sei se seria bem o objetivo desta JSR, mas acho faltou trabalhar um pouco mais de modularização, como por exemplo no uso desta com EJB’s, dependendo do tamanho do projeto, você acaba ficando com anotações em muitos lugares.

achei um pouco mais interessante, o aspecto como o spring trata este caso, se beneficiando de alguns recursos de AOP como poincuts, aumentando a modularização do projeto, quando este propósito é necessário.

Ainda falando sobre modularização, achei interessante o Spring OSGI, de forma que promete facilitar a divisão do projeto em módulos OSGI, possibilitando integração em tempo de deploy e execução. O glassfish faz bem isto, não asseguro até ponto, pois não testei, mas me parece uma alternativa interessante.

E respondendo, antes que me pergunte,

Pois é, queria justamente transparecer outro ponto de vista, e gostaria de saber como o Guice e/ou Seam, resolvem/poderia ser resolvido este problema ?

se não fosse isto, seria interessante seguir acrônimos recursivos

Rafael,

o JSR-299 possui dependências com EJB, e é possível injetar um Session Bean usando as anotações da nova especificação. Não vejo um esquecimento por parte dos caras dessa especificação.

OSGI é uma coisa bem baixo nível que não é necessário para a absoluta maioria das aplicações comuns que fazemos hoje em dia. Vale lembrar que OSGI não é a única forma de modularização, podemos muito bem separar nossas aplicações em jars, ears, wars… como sempre fazíamos e como vamos continuar a fazer.

O enterro dos xmls será responsável por uma maior modularização, já que poderemos criar configurações todo lugar, em qualquer módulo; não apenas num xml numa pasta específica do módulo principal.

Spring, Guice, PicoContainer e outros resolvem o problema da modularização através da injeção de dependência, e do incentivo de separar as interfaces das implementações.

[quote]Tudo bem que o nome WebBeans nao era o melhor, mas porque diabos esse povo gosta de arrumar sigla complicada que começa com J??? É algum tipo de fetiche???

JNI, JSF, JNDI, JSP, JDK, JRE, JPQP… [/quote]

Desculpa mas prefiro assim do que nome de comida ou de fruta!
Sei que nao agregou nada mais nao consegui ficar sem comentar!

não disse que não seria possível, quando me referi a falta de modularização, eu deveria ter mencionado por exemplo o caso dos interceptors.
pegue a especificação da JSR-299 e você verá no item “6.2.4.2 Interceptor bindings for stereotypes” um belo exemplo abaixo:

[quote]Interceptor bindings may be applied to a stereotype by annotating the stereotype annotation:@Transactional @Secure @Production @RequestScoped @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Action {}[/quote]
estas seriam uma das possibilidades que o interceptor poderá ser definido, declarado para um determinado estereótipo em qualquer Web Bean.
agora, imagine vários Web Beans, que detêm de várias anotações dentre estas acima declarados, você acaba perdendo um dos objetivos do AOP com perdendo um pouco do controle da modularização, deixando responsabilidades individuais acopladas, e com certa complexidade.

absoluta maioria você diz, apenas um contexto web para um servidor de aplicação com deploy de war ? caso sim, qual critério utilizda

O Guice é um ADI (Automatic Dependency Injector) moderno que se baseia em anotações e contextos ( chamados escopos). Os objetos não são singletons por default e o programador pode configurar as factories e contextos de injeção como quiser.
O Spring 2.0 canibalizou a mecanica do Guice de anotações mas deixou o legado do xml de configuração do Spring. O Guice é configurado totalmente via codigo ( que é uma alternativa muito melhor ao xml, porque o programador pode implementar uma leitura do XML se for necessário, e não como padrão). O guice resolve ainda problemas de referencia ciclica que o Spring não resolve.
O Seam tem um mecanismo semelhante de contextos, embora estes sejam amarrados ao ciclo de vida do JSF , enquanto os do Guice são amarrados ao ciclo de vida do JSP e Servlets.

O JCDI deixa claro ao que vêm ( em vez de webbeans) O J de Java é porque faz parte da plataforma Java.
O C é de contextos (escopos) que são o coração de um ADI onde se configuram as factories e outras formas de obter os objetos a injetar e o DI é a injeção propriamente dita.

Opa , explicou bem hein ? eheheh

Gostei bastante do post. Também dei uma olhada no Guice, e achei um espetáculo. As mecânicas de configurações do Spring são excelentes, o código foi extremamente bem bolado e produzido, cheios de javadoc e firulas; porém, funcionalmente a arquitetura do guice é mais enxuta e prática em relação ao spring.

Faltava um JCDI da vida pra produzir uma API em comum! Cada um usa agora o de sua preferência. Votei no Guice! :slight_smile:

… Isso é o que o JBoss Seam faz, não? (embora, é claro, não seja uma especificação mas um Framework…)

Abraços.
Elvano.

Exato Elvano, mas só funciona com JSF! O guice pode ser customizado… Eu sou fã do Seam, o acompanho desde a sua concepção, mas acho q ele pecou ao associar-se fortemente ao JSF! :-o

acho que o Seam foi essencial para evolucao do Java EE

publiquei post em meu blog sobre o assunto

Isso não é verdade já faz um tempo (antes da versão 2). Você pode usar o Seam com Wicket, GWT, Flex ou se preferir até mesmo de um client JavaSE, invocando via lookup EJB convencional uma Façade com componentes Seam.