On 26 Oct 2011, at 19:59, Linda DeMichiel wrote:
> Better late than never!
>
> Thanks, Pete -- more inline below....
>
> On 10/23/2011 10:13 AM, Pete Muir wrote:
>> 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).
>>
>
> I'm not sure I understand this correctly. Isn't CDI managing the Contexts? Or do you mean something else? Please explain.
The implementation of a context for a particular scope (annotation) is pluggable in CDI. With this in mind, it's completely conceivable for another spec to define the behaviour of a scope (e.g. Servlet define how the request scope behaves in an Http Servlet Request). I, at least, refer to this as the context (implementation).
A single scope (annotation) can have multiple context implementations associated with it.
So, what Reza is proposing, and I discussed in more detail, is that CDI would continue to own the abstract/conceptual notion of a "request scope" (as it applies to more than just servlet, e.g. it applies to an EJB remote invocation as well, and can also apply in other environments such as ESB), but delegate the definition of how that scope behaves in an environment to the owning spec (e.g. Servlet).
>
>> 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?
>>
>
> Are you referring to the ability to inject *into* an entity, or inject an entity into something else?
I'm talking about the former.
Emmanuel has discussed the pros and cons of this in more detail in an email I will forward. I'm happy to defer to you guys on whether you want this in JPA or not. All I will say is I do see requests for this "in the wild".
>
> The former issue has arisen in the JPA expert group, and not received much support, as the design center
> of JPA has been to provide a lightweight O/R mapping layer, not on rich domain models.
> We have, however, added support for CDI injection into entity listeners.
>
> Injecting a "live" entity (one managed in a persistence context) into something else seems interesting,
> but I'm not sure that this is so easy to solve given that it seems that both the persistence provider
> and CDI would need to be managing its lifecycle. Were you referring to this? If so, could you
> sketch out how the CDI APIs work enable JPA to do this.
I don't think this is overly useful, as I think it abstracts too much away from something the user should be aware of, a call to database, which may be expensive.
This is easy enough to solve today in CDI with a producer method, which I think is a better solution probably.
>
>
>>> * @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?
>>
>
> I would like to echo the last question you raise.
>
>>> * 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.
>>
>>
>>