+1 for:
if blablabla ... non portable behaviour results.
Containers might log a warning. But simply failing to deploy might be a bit too aggressive imo.
LieGrue,
strub
>________________________________
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
>To: jsr345-experts_at_ejb-spec.java.net
>Cc: Jeremy Bauer <jrbauer_at_us.ibm.com>
>Sent: Monday, March 18, 2013 6:01 PM
>Subject: [ejb-spec users] [jsr345-experts] Re: IMPORTANT: Fwd: [jsr342-experts] transactional interceptors vs. EJB
>
>
>Hi Jeremy,
>
>I think the spec should say that they are not supported, and will
fail deployment, but that this restriction may be removed in a
future release.
>
>-marina
>
>
>On 3/18/13 9:31 AM, Jeremy Bauer wrote:
>
>Hi Marina,
>>
>>This does seem like the a good approach given all the subtleties. Question - what will be added to the spec make it illegal? For example, will the server be required to fail to deploy the module if it detects the use of @Transactional on a CMT EJB?
>>
>>-Jeremy
>>
>>
>>
>>From: Marina Vatkina <marina.vatkina_at_oracle.com>
>>To: jsr345-experts_at_ejb-spec.java.net, users_at_interceptors-spec.java.net,
>>Date: 03/15/2013 07:40 PM
>>Subject: [jsr345-experts] IMPORTANT: Fwd: [jsr342-experts] transactional interceptors vs. EJB
>>>>________________________________
>>
>>
>>
>>Please read this email sent to the Java EE EG.
>>
>>This proposal reduces the complexity of mixing transactional
interceptors
with CMT rules in the EJB spec, by restricting their use in the
EJBs.
>>
>>I will also remove the current (and quite confusing) statements
from the
Interceptors spec that transaction context of interceptors may
be changed
by transactional interceptors in the invocation chain.
>>
>>Best,
>>-marina
>>
>>-------- Original Message --------
>>Subject: [javaee-spec users] [jsr342-experts] transactional interceptors vs. EJB
>>Date: Fri, 15 Mar 2013 17:26:54 -0700
>>From: Bill Shannon <bill.shannon_at_oracle.com>
>>Reply-To: jsr342-experts_at_javaee-spec.java.net
>>To: jsr342-experts_at_javaee-spec.java.net
>>
>>
>>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.
>>
>>
>>
>>
>
>
>