[jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-2262) When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.

[Carlo de Wolf (JIRA)]

    [ https://issues.jboss.org/browse/EJBTHREE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628169#comment-12628169 ] 

Carlo de Wolf commented on EJBTHREE-2262:
-----------------------------------------

Now for the red-herring bit:
{noformat}
diff --git a/src/org/jboss/tutorial/stateless/bean/CalculatorBean.java b/src/org/jboss/tutorial/stateless/bean/CalculatorBean.java
index 9c04cde..3824e6e 100644
--- a/src/org/jboss/tutorial/stateless/bean/CalculatorBean.java
+++ b/src/org/jboss/tutorial/stateless/bean/CalculatorBean.java
@@ -48,7 +48,7 @@ public class CalculatorBean implements CalculatorRemote, CalculatorLocal
       return x - y;
    }
 
-       @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
+       //@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
        public void throwException()
                throws MyException
        {
{noformat}

{noformat}
16:53:48,662 ERROR [STDERR] org.jboss.tutorial.stateless.bean.MyException: Alert! Alert!
{noformat}

The code works, because TransactionAttributeType.REQUIRED does take the throws clause into account.

> 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