Sorry for the delay on this, I thought my messages were getting through but on talking to Linda, it appears they never arrived ;-)
Hey Reza
Excellent list!
On 16 Oct 2011, at 21:09, Reza Rahman wrote:
> Bill,
>
> Sorry for the late reply to this. It took a while to get things back under control post-JavaOne. There are some very specific component unification items we were hoping to get accomplished in Java EE 6. The general gist is making sure all components across all Java EE JSRs (new and existing) support managed beans and do not frivolously create their own component models as well as aligning each Java EE API to each other. Here is a high level list (roughly in priority order):
>
> * Deprecate JSF @ManagedBean -- the redundancy right now is very confusing for developers.
> * Deprecate Java EE 6 @ManagedBean -- it's hardly ever used and creates a lot of confusion.
+1 from Red Hat :-)
> * Unify JSF and CDI scope definitions -- the overlap right now is very confusing. I don't think the answers are necessarily straight-forward. There basically needs to be a cohesive strategy now and going forward about where scopes are defined and maintained. The Java EE 6 approach is not necessarily entirely correct...
When we talk about scope and context, I make the following distinction.
A scope is the abstract notion of a context. For example, an application scope is an abstraction of the storage of contextual data for the length of a deployment on a server instance of an application. A session scope is an an abstraction of the storage of contextual data for the length of time a user is logged in.
A context is the application of the scope to a particular environment. For example, the session scope could be backed by an HttpSession orientated context.
So, what I would like to see is CDI retain ownership of the abstract notions of scope (at the API level, retain the annotations @ApplicationScoped, @SessionScoped, @RequestScoped and probably @ConversationScoped) but loose the definition of context (in general these should move to *Servlet* not JSF).
WDYT?
> * Separate EJB services from the component model and make them applicable to as many managed beans as possible, certainly simple "POJOs" a la CDI managed beans without any class-level component defining annotations.
Yes, top priority for Red Hat.
> * Reconcile the CDI/JPA life-cycle mismatch. The answers are not necessarily simple, but doable. It would be fantastic if @Entity was also a managed bean. Spring 3 can do this today.
This would be very powerful. AUIU this is primarily a "JPA" problem (simply in terms of determining who is concentrating on this). I think CDI offers the relevant APIs to allow JPA to hook in?
> * @Inject should work universally across all possible Java EE components including JSF validators/converters/phase listeners, bean validators, etc.
Yes.
> * @Inject should be able to inject JSF, Servlet, etc objects.
So I could actually inject a servlet instance into some other piece of code? I think this makes sense in some situations (e.g. inject the FacesContext or the ServletContext) but not in others (inject a servlet filter)? Do you have a broken down list here?
> * Redefining Servlets, etc as managed beans -- the most tantalizing benefits to this is being able to use the CDI SPI in Servlets and using @Alternative/_at_Interceptor throughout all Java EE components.
Yes/
> * Being able to use bean validation on method parameter beans for all managed beans, including JAX-RS, CDI, EJB, etc.
Yes, I think Emmanuel has this on his road map.
> * Using CDI event observers for JSF, Servlet, etc life-cycles.
Yes. We've added some of this into the EDR1 of CDI. Quite happy to move it wherever needed, just put it there for now to make sure it get's notice.