Mailing-List: contact commits-help@openejb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openejb.apache.org
Message-ID: <2129476992.1253894418475.JavaMail.jira@brutus>
Date: Fri, 25 Sep 2009 09:00:18 -0700 (PDT)
From: "Jean-Louis MONTEIRO (JIRA)" <jira@apache.org>
To: commits@openejb.apache.org
Subject: [jira] Closed: (OPENEJB-965)
 http://www.nabble.com/exceptions-handling-with-Webservices-td19668275.html
In-Reply-To: <1896306883.1228139924250.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/OPENEJB-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Louis MONTEIRO closed OPENEJB-965.
---------------------------------------

       Resolution: Fixed
    Fix Version/s: 3.1.2

TODO: create a test case for that ... I only have a sample/itest.

The EjbMethodInvoker will probably change when going to CXF 2.x, so we definitely have to enhance all tests around our web service implementation.

> http://www.nabble.com/exceptions-handling-with-Webservices-td19668275.html
> --------------------------------------------------------------------------
>
>                 Key: OPENEJB-965
>                 URL: https://issues.apache.org/jira/browse/OPENEJB-965
>             Project: OpenEJB
>          Issue Type: Bug
>          Components: webservices
>    Affects Versions: (trunk/openejb3)
>         Environment: All
>            Reporter: Jean-Louis MONTEIRO
>            Assignee: Jean-Louis MONTEIRO
>             Fix For: 3.1.2
>
>         Attachments: patch-openejb-965.txt
>
>
> As this problem becomes critical for applications, I have decided to open a JIRA.
> The full description is available at http://www.nabble.com/exceptions-handling-with-Webservices-td19668275.html
> Here are some thoughts.
> In the intercept method of the EjbInterceptor class (openejb-cxf module), we can either directly call the target EJB bean (when no handler has been defined) or delegate to the CXF chain when handlers have been defined.
> Regarding the first case, when an ApplicationException is thrown. This exception is caught by the preEjbInvoke method (from the EjbMethodInvoker). The preEjbInvoke method registers all exceptions as UNCHECKED so the client always receives a SOAPFaultException instead of the user defined application exception.
> We can work around this problem by adding a dummy handler or change the test to be sure it's always false.
> {code}
> line 82: if (binding.getHandlerChain() == null || binding.getHandlerChain().isEmpty()) {
> {code}
> To conclude, invoking directly the target EJB bean does not handle exceptions correctly. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.