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

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 824 Offline

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....

This message was edited 1 time. Last update was at 26/01/2009 18:09:44

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

edit: eis o futuro do JEE / sun mode

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 616 Offline

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

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,

Poxa, este cara até agora só falou do spring! O que tem a ver com o tópico ?

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

josenaldo wrote: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????

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

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 824 Offline

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.

JavaTeenager Membro desde: 04/06/2006 13:50:18 Mensagens: 155 Offline

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...

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

This message was edited 1 time. Last update was at 29/01/2009 01:46:07

Leonardo3001 wrote: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.

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:

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 {}

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.

Leonardo3001 wrote: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.

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

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3187 Online

faelcavalcanti wrote:

Poxa, este cara até agora só falou do spring! O que tem a ver com o tópico ?

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

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

Notícias, artigos e o maior fórum brasileiro sobre Java