[
https://issues.jboss.org/browse/EJBTHREE-2262?page=com.atlassian.jira.plu...
]
Shaun Appleton commented on EJBTHREE-2262:
------------------------------------------
Yes but this issue is about an exception not having @ApplicationException (which is why it
is not in the test).
An application exception should not be wrapped ie. the Application Exception is thrown
back to the client.
Other exceptions get wrapped in an EJBException.
The transaction demarcation is irrelevant.
Now, at the moment, when @ApplicationException is not explicitly used
the exception behaves as a non-application exception (ie gets wrapped) when using
NOT_SUPPORTED
whereas
the exception behaves as an application exception when not using NOT_SUPPORTED
So there is a switch in behaviour based on transaction demarcation - which should be
irrelevant.
When throwing an application exception in a method that is annotated
with NOT_SUPPORTED it should not wrap the application Exception.
-------------------------------------------------------------------------------------------------------------------------------------
Key: EJBTHREE-2262
URL:
https://issues.jboss.org/browse/EJBTHREE-2262
Project: EJB 3.0
Issue Type: Bug
Reporter: Shaun Appleton
Attachments: stateless_00500318.zip
When throwing an application exception in a method that is annotated with NOT_SUPPORTED
it should not wrap the application Exception.
What currently happen is that it is wrapped in an EJBException instead of being thrown
un-wrapped.
See Table 14 p361. of jsr-220 spec
This has been tested on EAP 5.1.0
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira