http://www.guj.com.br/posts/list/17.java JForum - http://www.jforum.net
É 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.
]]> http://www.guj.com.br/prepost/116032/627677/web-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/627677/web-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT http://www.guj.com.br/prepost/116032/627826/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/627826/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
edit: eis o futuro do JEE / sun mode]]> http://www.guj.com.br/prepost/116032/628135/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/628135/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT 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 ]]> http://www.guj.com.br/prepost/116032/628205/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/628205/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT http://www.guj.com.br/prepost/116032/628221/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/628221/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT http://www.guj.com.br/prepost/116032/628243/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/628243/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
JNI, JSF, JNDI, JSP, JDK, JRE, JPQP... ]]> http://www.guj.com.br/prepost/116032/628262/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/628262/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT ]]> http://www.guj.com.br/prepost/116032/628301/web-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/628301/web-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT http://www.guj.com.br/prepost/116032/628324/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/628324/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
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 [url=http://www.springsource.org/osgi]Spring OSGI[/url], de forma que promete facilitar a divisão do projeto em módulos OSGI, possibilitando integração em tempo de deploy e execução. [url=http://weblogs.java.net/blog/ss141213/archive/2008/04/glassfish_v3_on.html]O glassfish faz bem isto[/url], não asseguro até ponto, pois não testei, mas me parece uma alternativa interessante.

E respondendo, antes que me pergunte,
[quote]Poxa, este cara até agora só falou do spring! O que tem a ver com o tópico ?[/quote]
Pois é, queria justamente transparecer outro ponto de vista, e gostaria de saber como o [url=http://code.google.com/p/google-guice/]Guice[/url] e/ou [url=http://www.seamframework.org/]Seam[/url], resolvem/poderia ser resolvido este problema ?

[quote=josenaldo]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????[/quote]
se não fosse isto, seria interessante seguir [url=http://pt.wikipedia.org/wiki/Acr%C3%B3nimo#Acr.C3.B3nimo_recursivo]acrônimos recursivos[/url]]]> http://www.guj.com.br/prepost/116032/629091/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/629091/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
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.]]> http://www.guj.com.br/prepost/116032/629347/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/629347/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
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!]]> http://www.guj.com.br/prepost/116032/629632/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/629632/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT 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 "[b]6.2.4.2 Interceptor bindings for stereotypes[/b]" um belo exemplo abaixo:

[quote]Interceptor bindings may be applied to a stereotype by annotating the stereotype annotation:[code]@Transactional
@Secure
@Production
@RequestScoped
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface Action {}[/code][/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.

[quote=Leonardo3001]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.[/quote]
absoluta maioria você diz, apenas um contexto web para um servidor de aplicação com deploy de war ? caso sim, qual critério utilizda
]]> http://www.guj.com.br/prepost/116032/629943/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/629943/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT [quote]Poxa, este cara até agora só falou do spring! O que tem a ver com o tópico ?[/quote]
Pois é, queria justamente transparecer outro ponto de vista, e gostaria de saber como o [url=http://code.google.com/p/google-guice/]Guice[/url] e/ou [url=http://www.seamframework.org/]Seam[/url], resolvem/poderia ser resolvido este problema ?
[/quote]

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.]]> http://www.guj.com.br/prepost/116032/629995/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/629995/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT http://www.guj.com.br/prepost/116032/629996/web-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/629996/web-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
Faltava um JCDI da vida pra produzir uma API em comum! Cada um usa agora o de sua preferência. Votei no Guice! ]]> http://www.guj.com.br/prepost/116032/635591/web-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/635591/web-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
... Isso é o que o JBoss Seam faz, não? (embora, é claro, não seja uma especificação mas um Framework...)

Abraços.
Elvano.]]> http://www.guj.com.br/prepost/116032/637473/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/637473/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT ]]> http://www.guj.com.br/prepost/116032/637786/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/637786/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
publiquei post em meu blog sobre o assunto
http://faelcavalcanti.wordpress.com/2009/02/15/entendendo-proposito-jsr-299-jcdiweb-beans/]]> http://www.guj.com.br/prepost/116032/641338/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/641338/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT [/quote]


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.]]> http://www.guj.com.br/prepost/116032/641342/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/641342/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT [quote]Você pode usar o Seam com Wicket, GWT, Flex[/quote]

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...) [b]usando o GWT???[/b].

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

[b]Problema potencial:[/b] no livro Seam in action, o autor Dan Allen diz:

[quote]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.[/quote]

e

[quote]Unfortunately, the future of this project is unknown beyond the release of Seam 2. Ajax4jsf was
adopted by JBoss, but G4jsf was left behind.[/quote]. Logo, pelo que entendi, teriamos somente chamadas remotas (RPC) pra interargir da UI cliente com o lado Seam no servidor, eh isso mesmo?

[b]Entao, qual o futuro do Seam+GWT?.[/b]. Robustez, escalabilidade, manutenabilidade, etc, qual sua opinião..? (sem querer abusar...)

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

Abraços, elvano.

]]> http://www.guj.com.br/prepost/116032/641372/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/641372/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
Fora que hoje a Red Hat [url=http://www.guj.com.br/posts/list/112553.java]esta investindo[/url] 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 [u]opinião pessoal[/u], 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.]]> http://www.guj.com.br/prepost/116032/641423/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/641423/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
Bem, se houver... A investida é boa! ]]> http://www.guj.com.br/prepost/116032/641843/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/641843/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT
]]> http://www.guj.com.br/prepost/116032/641853/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection http://www.guj.com.br/prepost/116032/641853/reweb-beans-morreu-agora-se-chama-jcdi-java-contexts-and-dependency-injection GMT