Date: Tue, 18 Oct 2011 02:12:10 +0200
Bill/Reza/all,
Thanks a lot for the effort and great input.
@Reza you're right, ongoing contribution by people like yourself matter more
than labels, titles or "medals"[?]
On Tue, Oct 18, 2011 at 1:25 AM, Bill Shannon <bill.shannon_at_oracle.com>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.
>
>
EE8 and beyond with true modularity will require a different approach to
that, by declaring something "optional", thus allowing an app to function
properly without having to use or load it.
So unless something was crucial now in EE 7 I would probably postpone other
cases and think about a good and reasonable module structure and profiles
then.
>
> * 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.
>
Where applicable, EE 8 may also benefit from the new Java Identity JSR (351)
currently not scheduled before early 2013, thus it looks a bit too late for
7.
>
> What other services did you have in mind?
>
> See above, SSO would be a key main feature from 351 in its current
proposal.
>
> * 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.
>>
>
> Yes.
Speaking of Bean Validation. As I both help JSR-308 with some of their
Checkers and am about to refactor a client's older web application into the
Java EE 6 era where possible, I can't help but notice certain overlaps in
core annotations, at least NotNull vs. NonNull.
Bean Validation has got javax.validation.constraints.NotNull
While from Java 8 on some (package still TBD) form of checkers like this are
likely to enter parts of the Java Platform.
http://code.google.com/p/checker-framework/source/browse/checkers/src/checkers/nullness/quals/NonNull.java
At JSR Lightning Talks during JavaOne, those representing JSR-310
(Date/Time) said, there is interest by the JDK team to also use the new
classes internally and rewrite portions of it based on the new API. If
that's something EE also would consider, then many parts of EE 8 were to be
heavily influenced and changed. JDBC, JSF or JSP/JSTL just to name a few,
every single part that uses Date and Time in this case.
NotNull as opposed to a more generic NonNull probably affects less code,
given Bean Validation isn't around as long as java.util.Date or other
related classes, but before considering broader usage of it in other JSRs, I
would also look a bit onto what changes it may undergo beyond Java 8. E.g.
by things moving either into the platform or other JSRs from 8 to be
considered.
Sorry to throw in a lot here. Trying to help prioritize and maybe identify
those parts that may or are certain to change further from EE8 on, thus
touching and changing things twice may in some cases be avoided.
Unless there are quick and easy ones with a great benefit if made available
sooner.
>
> * 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...
>
The JSF EG is also using JIRA quite actively.
Werner
(image/gif attachment: 329.gif)