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

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.

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!

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

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!

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

Ola

Alessandro, vou aproveitar que vc reacendeu a discussão e pedir pra ouvir sua opinião. Tenho lutado pra aprender bem JSF + RichFaces + Ajax4jsf …(JBoss).

No entanto, apesar de EU não gostar muito da aparência visual geral do Flex (caro, posso estilizar), esse me parece um pouco muito mais intuitivo e fácil de programar para a camada UI. Além disso, também me parece mais “profissinal, robusto” que GWT. Mas sou fã do GWT.

A minha pegunta é a seguinte, vc acha que é razoável, confiável, etc, implementar um sistema Enterprise (a princípio pequeno, mas com uma estratégia de crescimento para médio porte…) usando o GWT???.

É é que tenho a impressão (talvez errônea) de que o GWT é um framewok meio relegado para aplicações “pequenas”… Mas, se eu tiver indicios bons que o GWT pode “substituir” o lado cliente de forma robusta, pessoalmente não tenho dúvida em desistir do JSF em prol do GWT.

Problema potencial: no livro Seam in action, o autor Dan Allen diz:

G4jsf, a subproject under Ajax4jsf, is an integration library for the Google Widget Toolkit (GWT) and
JavaServer Faces (JSF). G4jsf combines both technologies to wrap Google widgets into JSF components.

e

Unfortunately, the future of this project is unknown beyond the release of Seam 2. Ajax4jsf was
adopted by JBoss, but G4jsf was left behind.

Entao, qual o futuro do Seam+GWT?.. Robustez, escalabilidade, manutenabilidade, etc, qual sua opinião…? (sem querer abusar…:))

(God, preciso aprender a fazer posts com menos palavras, :))

Abraços, elvano.

A dupla Seam + GWT já é a preferida da JBoss para desenvolvimento de suas aplicações web embarcada em seus frameworks, como é o caso do BRMS (Banco de Regras do Drools), Guvnor (novo Banco de Regras) e jBPM Console (ferramenta de monitoramento de processos BPM).

Fora que hoje a Red Hat esta investindo no próprio desenvolvimento do GWT, o que assim se pressupõe uma integração cada vez maior com seus frameworks como o caso do Seam.

Sem dúvida eu acho uma solução boa o desenvolvimento de interfaces com GWT para grandes projetos . Como opinião pessoal, a única coisa que não gosto muito do GWT é a burocracia para escrever coisas simples , ou melhor dizendo, desenvolvimento like Swing não me agrada.

Legal saber disso Allessandro, realmente assim fica um pouco melhor. Então falta resolver somente uma coisa no seam (já que não sabia da utilização em outros frameworks de visão): o forte acoplamento com EJB. Não vi ninguém ainda conseguir fazer um lookup de um EJB disponibilizado como componente Seam, ele o amarra deveras. Há alguma maneira de fazer isso?

Bem, se houver… A investida é boa!

Relaxa, isso tbm não é mais problema. Isso ocorria pq os componentes do Seam (EJBs ou POJOs) eram vinculados com o ciclo de vida JSF, o que não ocorre mais com os novos interceptors.