I agree that this is something a significant subset of developers want to be able to do, regardless of whether I agree with this approach.
I think injection into entities is easy enough to support (and should be possible from the CDI-perspective today, I know that the JPA EG have done something similar for entity listeners, and can likely take the same approach for entities).
It should also be possible to persist a CDI object, this is a really common gotcha for developers.
Lifecycle is a much harder problem, primarily because the life of a persistence context (which owns the lifecycle of an entity) is substantially different to the lifecycle of a CDI bean. I'm also not entirely sure of the exact use cases for trying to resolve this problem.
With this in mind, I would propose that we address this in two phases:
Phase 1: Support injection in entities. Require automatic unwrapping of any CDI proxy passed to the EntityManager.
Phase 2: Investigate lifecycle alignment between JPA and CDI
WDYT?
On 26 Oct 2011, at 03:18, Reza Rahman wrote:
> Linda,
>
> This pertains to a problem/limitation commonly observed by Java EE 6/CDI/JPA 2 users.
>
> The first symptom of the problem happens quite frequently. Users (especially users new to Java EE) often expect something like this to work:
>
> <table>
> <tr>
> <td>Bidder</td>
> <td><h:inputText value="#{bid.bidder}"/></td>
> </tr>
> <tr>
> <td>Item</td>
> <td><h:inputText value="#{bid.item}"/></td>
> </tr>
> <tr>
> <td>Bid Amount</td>
> <td><h:inputText value="#{bid.bidPrice}"/></td>
> </tr>
> </table>
> <h:commandButton type="submit" value="Add Bid" action="#{placeBid.addBid}"/>
>
> @Named @RequestScoped @Entity @Table(name=“BIDS”)
> public class Bid {
> @Id @GeneratedValue @Column(name=“BID_ID”)
> public Long bidId;
> public String bidder;
> public String item;
>
> @Column(name=“BID_PRICE”)
> public Double bidPrice;
> }
>
> @RequestScoped @Named(“placeBid”) @Stateless
> public class PlaceBidBean {
> @PersistenceContext private EntityManager entityManager;
> @Inject private Bid bid;
>
> public void addBid() {
> entityManager.persist(bid);
> }
> }
>
> The current workaround is to use CDI producers and instantiate entities manually in those producers. The solution is unintuitive to say the least and often turns off Java EE newbies.
>
> The second symptom is more profound and typically happens in more advanced systems using domain driven design. In such systems, entities are rich domain objects that can internally utilize service (aka business components) and repository objects (aka DAOs). Users expect to be able to inject these objects directly into entities, whether the entities are created at the orchestration layer (as in the example above) or retrieved as a result of a JPA query. Spring currently solves this problem via the @Configurable annotation: http://amin-mc.blogspot.com/2008/02/configurable-example-with-spring-25.html. The only workaround in Java EE is quite ugly: reverting back to old-fashioned look-ups in domain objects. This leads to the impression that Java EE really does not support domain driven design while Spring does.
>
> I think the solution to this problem isn't that complicated - it basically consists of JPA implementations being aware of the fact that they may be passed CDI managed beans and in CDI environments, entities should be internally instantiated via CDI instead of the new operator.
>
> There are intricacies here though -- namely making sure that the JPA entity/entity manager life-cycle does not conflict with the CDI scope/life-cycle. I imagine these intricacies could be worked through via a collaboration between JPA experts (which I do not consider myself to be principally because persistence is not a core interest for me personally) and CDI experts. If Resin 4 "owned" it's own JPA implementation (it simply ships EclipseLink), we would have probably already solved this problem in Resin 4. Alas, that's unlikely to ever be the case given our small, focused development team.
>
> Hope this makes sense. If anything needs to be further clarified, I am happy to do it...
>
> Cheers,
> Reza
>
>
> On 10/17/2011 7:52 PM, Linda DeMichiel wrote:
>>
>>
>> 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...
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.1831 / Virus Database: 2090/4558 - Release Date: 10/17/11
>>
>>
>