[jsr342-experts] Re: Modularity in Java EE 7

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Mon, 17 Oct 2011 16:25:04 -0700

Reza Rahman wrote on 10/16/11 13:09:
> 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):

This is a good list. Let's keep adding to it and filling in the details.

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

As a matter of policy, we don't deprecate anything except for the most
serious errors. We can update the docs to make it clear what you should
and should not use, but we're not likely to deprecate them.

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

Can you fill in a few details about what you think is broken and what we
might be able to do to fix it?

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

Our plan is to do this for transactions in EE 7.

We should consider security for EE 8.

What other services did you have in mind?

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

I'll let Linda comment on this.

> * @Inject should work universally across all possible Java EE components
> including JSF validators/converters/phase listeners, bean validators, etc.

Yes. Let's make a list of the container managed objects that should be
added to table EE.5-1 in the platform spec.

> * @Inject should be able to inject JSF, Servlet, etc objects.

What would it mean to (for example) inject a Servlet object into a
managed bean?

Would you get the same instance of the Servlet that the web container
is using? Would you get your own instance?

When would this be useful? What's the use case?

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

You should already be able to use the CDI SPI in Servlets, right?
What prevents that currently?

Do you want to use interceptors on Servlets instead of Servlet filters?

There are open issues with the use of @Alternative when applied to base
Java EE annotations or objects. As currently implemented, the base
annotation processing doesn't have knowledge of CDI-specific annotations,
and so isn't able to take @Alternative into account when discovering
(e.g.) Servlets.

> * Being able to use bean validation on method parameter beans for all
> managed beans, including JAX-RS, CDI, EJB, etc.


> * Using CDI event observers for JSF, Servlet, etc life-cycles.

That would mean defining new lifecycle events that the container would emit?

> I don't think this is a complete list -- I didn't really get the time to
> look at this in great detail. If it is helpful to elaborate these as
> separate JIRA issues, let me know -- I'll be happy to do it. That being
> said, I really like Nigel's approach in JMS 2 in that he simply
> assimilates these high level suggestions and creates detailed JIRA
> issues from them himself :-).

Linda is still thinking about how best to track these issues, but I assume
we'll be using Jira at some point...