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.
* 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...
* 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.
* 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.
* @Inject should work universally across all possible Java EE components
including JSF validators/converters/phase listeners, bean validators, etc.
* @Inject should be able to inject JSF, Servlet, etc objects.
* 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.
* 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.
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 :-).
Cheers,
Reza
On 9/29/2011 2:38 AM, Bill Shannon wrote:
> Jason T. Greene wrote on 09/28/2011 08:32 PM:
>> On Sep 27, 2011, at 4:57 PM, Bill Shannon <bill.shannon_at_oracle.com>
>> wrote:
>>
>>> Jason T. Greene wrote on 9/27/11 1:51 PM:
>>>> On 9/27/11 2:56 PM, Bill Shannon wrote:
>>>>
>>>> -snip-
>>>>
>>>>> We have considered several
>>>>> alternatives moving forward, including delivering Java EE 7 with the
>>>>> remaining content as planned, or splitting the Java EE 7 release into
>>>>> smaller Java EE 7 and Java EE 8 releases, with only a small time gap
>>>>> between those two releases, and with Java EE 8 containing only
>>>>> modularity support and any remaining original content from Java EE 7.
>>>>>
>>>>> I know this will be a disappointment to all of us, but I'm sure
>>>>> you'll
>>>>> understand the constraints and agree that alignment with the upcoming
>>>>> Java SE module system is essential.
>>>>
>>>> Hi Bill,
>>>>
>>>> I definitely think this was the right decision to make, and relay
>>>> Red Hat's
>>>> support. Due to the massive impact modularity will have I think
>>>> it's more
>>>> important that EE and SE be cleanly aligned, then for us to be early.
>>>
>>> Thanks for the support.
>>>
>>>> The idea you mention above of fast tracking EE7 is interesting.
>>>> Does this imply
>>>> revisiting the main goals? We would love to see some more work on
>>>> unifying the
>>>> specs (e.g. common services like tx, sec, and so on), and that
>>>> seems more
>>>> achievable in a short time frame.
>>>
>>> At this point we're just collecting input.
>>>
>>> It sounds like you're suggesting that we scale back some (unnamed)
>>> goals
>>> and doing more work to unify specs. We're still considering the
>>> resource
>>> impact of the various possibilities but at this point we think we'd
>>> likely
>>> have to remove more than just modularity to make a significant
>>> difference
>>> in the EE 7 schedule.
>>
>> That's correct. I was assuming that a shortened schedule would mean
>> shifting or
>> splitting other major items. For example, perhaps some of the PAAS
>> work could be
>> split between 7 and 8?
>
> The only obvious choice there is to defer the limited SaaS support we're
> planning to EE 8. I'd be a little worried about doing that, however,
> since we've already seen that there's an interaction between the metadata
> we need for PaaS and the metadata we need for SaaS. The nice simple
> solution we envisioned for PaaS can become quite complicated when we
> factor in the SaaS requirements. I'm concerned that if we don't
> consider them from the beginning we'll end up with a mess if we have
> to retrofit them later.
>
>>> Still, I'm interested in what additional spec unification you'd like
>>> to see.
>>>
>>
>> Well I think we could continue to build on the "unified component
>> model" notions
>> we introduced in 6. More specifically taking things like EJB
>> transactional
>> annotations and making them common EE services that can be consumed
>> by managed
>> beans, and by extension any EE framework.
>
> Doing that for transactions is already on our list.
>
> Anything else?
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1809 / Virus Database: 2085/4525 - Release Date: 09/28/11
>
>