On 10/17/2011 4:25 PM, Bill Shannon wrote:
> 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.
Reza, please explain what you have in mind here.
>
>> * @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.
>
> Yes.
>
>> * 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...