Marina and I have had many discussions about this! :-)
Ideally, I would say that this is illegal, applications MUST NOT do this,
and products MUST detect this at deployment time and fail the deployment.
But...
It's very late for this release, and it's not clear we can deal with all
the implementation issues related to detecting this at deployment time,
so, I'm expecting that we'll be more flexible, at least for this release.
I would propose changing "MUST" to "SHOULD" above, which conveys the
intent while allowing some flexibility.
We could argue about whether we should say this is "illegal" or
"not supported". I chose "illegal" because it more clearly conveyed
that applications shouldn't do this, and it more clearly conveyed
that the implementation could detect this and fail the application
in some way.
Does that seem acceptable?
Kevin Sutter wrote on 03/18/13 11:46:
> Hi Bill,
> Not sure how or if the EJB discussion on this topic comes back to the Java EE
> EG, but I had raised this question to Jeremy (the IBM rep for EJB):
>
>> ..that we should just tell developers to never do this, and add a special case
> to make this
> illegal.
> How will this detection be communicated to the end user?
>
> The conversation on the EJB EG is here:
> http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2013-03/message/58
>
> Maybe you and Marina have regular discussions, so this is not an issue. I just
> didn't want to lose track of this discussion. Thanks.
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> Kevin Sutter, Java EE and Java Persistence API (JPA) architect
> mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
> http://webspherepersistence.blogspot.com/
> phone: tl-553-3620 (office), 507-253-3620 (office)
> http://openjpa.apache.org/
>
>
>
>
> From: Bill Shannon <bill.shannon_at_oracle.com>
> To: jsr342-experts_at_javaee-spec.java.net,
> Date: 03/15/2013 07:46 PM
> Subject: [jsr342-experts] transactional interceptors vs. EJB
> --------------------------------------------------------------------------------
>
>
>
> The new @Transactional annotation in JTA is implemented as an
> interceptor. We didn't have to add any special support for
> transactional interceptors, we just used the general interceptor
> support in a specific way to provide this new capability.
>
> That's a good thing. Fewer special cases, more generality.
>
> The EJB spec first introduced the idea of interceptors, and we
> want interceptors of all kinds to continue to be usable with EJBs.
>
> Again, a good thing. General capabilities combined orthogonally.
>
> EJB already supports Container Managed Transactions, but there have
> been concerns about how CMT interacts with the new transactional
> interceptors that generalize this capability for all beans. We've
> specified how these capabilities work so that it makes their
> interaction well-defined, although it can be complex to understand
> exactly what happens in all cases. In many cases, the interaction is
> complex enough that most people will be better off never trying to use
> the new transactional interceptors with EJBs.
>
> Still, we've resisted making this illegal.
>
> After introducing new general capabilities that remove special cases,
> we didn't want to add a new special case. We didn't want people to
> believe that some kinds of interceptors can't be used with EJBs.
> And we didn't want platform implementors to fail to implement
> interceptor support for EJBs in a way that would prevent this, and
> potentially other, cases from working.
>
> As we've worked through more of the details of transactional
> interceptors, especially for lifecycle methods (see my earlier message
> to the expert group), we've had a change of heart.
>
> We're now convinced that the interactions between EJB CMT and transactional
> interceptors are subtle enough and complex enough that we should just
> tell developers to never do this, and add a special case to make this
> illegal.
>
> I know some of you will be happy with this result. :-)
>
> For others, remember that we always have the option of removing this
> restriction in a future release, if needed.
>
> Lacking any immediate negative feedback, we'll add this special case
> restriction to the EJB spec.
>
> Thanks.
>
>