From: <reza_rahman_at_lycos.com>
Date: Wed, 26 Oct 2011 14:26:43 +0000 (GMT)

Werner,

Note, I didn't say that the Spring 3.0 solution is great :-). The issue with @Configurable is that it depends on compile-time AOP, which is a pain even for the most technically adept teams. That should not be an issue in Java EE since we control the class-loader. So, in effect, a Java EE centric solution to the problem should be more usable than Spring :-). That all being said, I have used @Configurable myself in domain driven design systems and it can work quite smoothly once the deployment/build is setup correctly.

Cheers,
Reza


Oct 26, 2011 06:38:34 AM, jsr342-experts@javaee-spec.java.net wrote:

Reza,

Thanks for the example.
Although using Spring IOC in a pre-EE6 era project, we also faced numerous problems between the lifecycles of JPA2 and JTA managed by Spring. There are a couple of approaches, but given a history of Spring code without annotations and the strong need for staging and configuration() annotations were not an option there.
Thus @Transactional was used in combination with AOP for distributed transations and multiple datasources
(This article comes closest: http://www.binaris-informatik.de/?p=726 sorry I didn't come across an English one in this short time, but the charts and terms are mostly English anyway)

I'm not sure, if the new (JPA2) code and entities used @Configurable, but where it did we certainly suffered from issues like this: http://stackoverflow.com/questions/828747/why-does-springs-configurable-sometimes-work-and-sometimes-not
The combination of Hibernate as JPA implementation and AspectJ/AOP also matches that scenario.

We used Domain Driven Design, and at least the mix of Spring for JTA including JPA2 almost caused the project to fail miserably.
So claiming Spring does DDD while JavaEE can't is not a one size fits all answer
What our example as well as many of recent arguments show, is that JSRs in EE7 and beyond must be further coordinated.
JTA+JPA+JMS (another puzzle piece we used, there I can clearly say, some people insisting on Spring JMS Templates instead of Message Driven Beans which both I and another consultant saw work on a much bigger scale) plus a couple more components should work together well and of course make an Agile approach as easy as possible.

It isn't just enough to point out Agility in the JCP itself, we also have to support it for technologies and its customers.

Werner

On Wed, Oct 26, 2011 at 4:18 AM, Reza Rahman <reza_rahman@lycos.com> 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:

Bidder
Item
Bid Amount

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