An early draft review of JSR-299 "Web Beans" snuck out the door last Friday, despite some technical problems with the JCP site. Web Beans, a melding of concepts from annotation-friendly Java 5 frameworks like JBoss Seam and Google Guice, looks to be Java's answer to other frameworks based on dynamic languages. At its core, Web Beans aims to provide a powerful, contextual-driven component model with a sophisticated, type-safe dependency injection mechanism. From the draft:

Web Beans allows EJB 3.0 components to be used as JSF managed beans, thus unifying the component models of EJB and JSF and significantly simplifying the programming model when EJB and JSF are used together.

A series of sneak peek articles written by Gavin King, spec lead, came out prior to the draft and give some background and context to the draft.

it is not released from the JCP site and it lack very much of its content,and no examples at all not very usefull!!!

it is not released from the JCP site

It is now: http://jcp.org/aboutJava/communityprocess/edr/jsr299/ The JCP site is having many technical issues at the moment, hence the delay.

and it lack very much of its content

It's an *early* draft. The idea of an early draft is to get community involvement and feedback early in the process of designing a spec.

and no examples at all not very usefull!!!

There's lots of examples of components. Well, its true that there is no full worked example of an *application*, but that's not typical in specs, right?

This effort is long over due although I am not sure why it is not part of JSF 2.0. For me, getting a standard way of doing this into JSF is key for it to jump to the next level of usability. I do have some concerns. Particular is the fact that there can be only one "Web Conversation" associated with a JSF request.

• Any JSF request has exactly one associated conversation • The conversation associated with a JSF request is determined at the end of the restore view phase and does not change during the request

What about navigation? Say I begin the request with view A and I want to navigate to view B. I want view A to be associated with conversation A' and view B to be assocaited with conversation B'. Will that work and why not? By saying a Web Container has to support JTA transactions is pretty much saying you have to be using J2EE. Why make that requirement, optional yes, required no. Ditto for JTA persistence.

Web Beans provides JPA persistence contexts scoped to the Web Beans conversation.

JPA is certainly a good implementation choice but that is an implementation detail not a specification requirement. There are also other features that seem to be crossing over into the EJB/J2EE realm like Interceptors, neat but I don't want to be locked into J2EE. Anyway will give it a re-read as I appreciate what JBOSS is doing.

This effort is long over due although I am not sure why it is not part of JSF 2.0.

Well, partly so that the component model is agnostic of JSF.

What about navigation? Say I begin the request with view A and I want to navigate to view B. I want view A to be associated with conversation A' and view B to be assocaited with conversation B'. Will that work and why not?

You want to change conversation in the middle of a faces form submission? Why? I have found almost no usecases for doing this... W.R.T. dependencies upon things like JPA and the EE environment, this is definitely something we are looking to minimize, since we have had a lot of feedback that this work is useful outside the EE environment. But note that just because the spec includes integration with a technology like JPA does not necessarily create a hard dependency to JPA. You could still integrate Hibernate or something else if you prefer. Web Beans is designed to be deeply extensible.