jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: Modularity in Java EE 7

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Tue, 25 Oct 2011 22:18:26 -0400

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
>
>