The problem with a warning is that somebody may not pay attention to it
and the bean will behave not as expected.
The problem with a "non-portable" statement is bigger: it can mean that
some container can support it.
-marina
On 3/18/13 11:05 AM, Mark Struberg wrote:
>
> +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.
>>>
>>>
>>>
>>>
>>
>>