Hi all,
I like the number #6 which is the more comprehensive approach for end users.
The exception wrapping is closely linked with remoting stuff and has been
propagated to local invocations.
In local mode, I would prefer to not wrap by default but that is not
compliant with previous specs versions.
Anyway, #6 is definitely my favorite choice.
The @DontWrapException or so is equivalent to declaring any exception as an
ApplicationException in the ejb-jar.xml, right ?
If yes, do we really need that additional exception?
I guess we don't need it, because if we are throwing external exceptions,
we still need to declare them in the ejb-jar.xml file (we can't change a
provided library to add a new annotation). If the exception is internal to
the module or application, we can still use the @ApplicationException. Am I
wrong?
Jean-Louis
2012/2/17 Marina Vatkina <marina.vatkina_at_oracle.com>
> Experts,
>
> Please cast your votes on the options below. If you do not have a
> preference for the CDI behavior, please vote on what the EJB behavior
> should be.
>
> thanks,
> -marina
>
>
> Linda DeMichiel wrote:
>
>> This is an item that is even more directly relevant to EJB.
>> Again, we'd appreciate your feedback.
>>
>> The issue is how the new transactional interceptors should (or
>> shouldn't) interact with EJB CMT. Please consider this issue not
>> just from an EJB point of view, but in view of the interaction
>> of EJB components in CDI applications using transactional
>> interceptors.
>>
>> Please post either here, on the users list, or on the javaee-spec
>> users list.
>>
>> thanks again,
>>
>> -Linda
>>
>>
>> -------- Original Message --------
>> Subject: [jsr342-experts] EJBs and JTA transactional interceptors
>> Date: Mon, 30 Jan 2012 12:40:16 -0800
>> From: Bill Shannon <bill.shannon_at_oracle.com>
>> Reply-To: jsr342-experts_at_javaee-spec.**java.net<jsr342-experts_at_javaee-spec.java.net>
>> To: jsr342-experts_at_javaee-spec.**java.net<jsr342-experts_at_javaee-spec.java.net>
>>
>> We've been trying to figure out how the new JTA transactional interceptor
>> support should interact with EJBs. Here's some options we've considered:
>>
>> 1. The new transaction annotations are not allowed to be used on EJBs.
>> This error would be detected at deployment time.
>>
>> 2. The new transaction annotations have no effect when used on EJBs.
>> This would likely be very surprising to users.
>>
>> 3. The EJB container does not understand the new transaction annotations
>> at all and behaves the same with regard to the exceptions that are
>> thrown
>> as it would if the application were to throw the same exceptions in
>> an EJB that was not annotated with the new transaction annotations.
>> The exceptions the EJB container sees at point B above are handled
>> the same as they would be if CDI were removed from the picture.
>> The EJB container does exception wrapping and transaction rollback
>> based only on its existing rules, including use of the existing
>> EJB @ApplicationException annotation. At point A the application
>> sees exceptions that might be wrapped in the normal EJB way.
>>
>> Note that the EJB container will be performing its normal CMT
>> behavior, including the default transaction attribute of REQUIRES
>> and the normal EJB exception wrapping behavior. If the EJB Bean
>> wants to use the new JTA transaction annotations it will likely want
>> to disable the EJB CMT support by specifying an EJB transaction
>> attribute of SUPPORTS (which means the EJB container will never
>> start a transaction itself and will pass through any existing
>> transaction context).
>>
>> 4. Like #3, but the EJB container understands both the existing
>> EJB @ApplicationException annotation as well as any new such
>> annotation defined by JTA. This changes which exceptions will
>> be wrapped before returning to the application, and what will
>> happen to any transaction that the EJB container might have started.
>>
>> And like #3, the application will likely want to disable EJB CMT
>> by specifying an EJB transaction attribute of SUPPORTS.
>>
>> 5. Like #4, but the EJB container also detects the use of the new
>> JTA transaction annotations and changes the default CMT behavior
>> to SUPPORTS.
>>
>> And like #4, the EJB container still does its normal exception wrapping.
>>
>> 6. Like #5, but the EJB container also changes the exception wrapping
>> rules to match those of a standalone CDI bean using the new JTA
>> transaction annotations (i.e., no exception wrapping at all).
>>
>>
>>
>> In cases #5 and #6, it's TBD what should happen if the bean uses both
>> the EJB transaction annotations and the JTA transaction annotations.
>> Given a possible implementation (see appendix), you can predict the
>> effect, but it's almost certainly not what the user wants, and so
>> likely should be treated as an error, probably detected at deployment
>> time.
>>
>> The current EJB exception wrapping behavior is somewhat arcane. You
>> could imagine a new EJB annotation @DontWrapExceptions that would
>> disable this behavior. This could be used explicitly in cases
>> #3 - #5 (it's implicit in case #6), or in other existing uses of EJB.
>>
>> Note that remote EJBs would need to continue to follow the existing
>> rules for remote exceptions.
>>
>> Which option above do you prefer?
>>
>>
>>
>>
>>
>> --- Appendix (read only if you're confused)
>>
>> For the options #3 - #6, it's helpful to think about how
>> this might be implemented. For example, consider an
>> implementation where the EJB container asks CDI to instantiate
>> the class that is the EJB bean. CDI performs injection on
>> the bean and returns a wrapper or subclass of the bean that
>> handles any interceptors declared for the bean. The EJB
>> container then invokes methods on the bean using this object
>> reference returned by CDI. The EJB container does no
>> interceptor handling of its own. This may or may not be a
>> reasonable or correct implementation approach, but for the
>> purposes of the following, let's consider it. Here's a picture:
>>
>> app reference ----> EJB container ----> CDI ----> EJB bean
>> A B
>>
>