You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by uglything <ju...@gmail.com> on 2008/09/25 14:12:46 UTC

exceptions handling with Webservices

Hie.

Here is my problem :

I have a webservice defined in an OpenEJB server (embedded CXF and JAXB-WS)

This webservice declares a method that throws a checked exception that
is declared as a @WebFault.

When the client calls the server and when the webmethod sends an
exception, the client receives a generic SoapFaultException with an
ApplicationException inside.
I expected my client to receive my business checked exception...

After having investigated a little bit, it appears that the
WebFaultOutInterceptor class in the bundled CXF version works as
follow :

When a fault is generated, it gets the cause. If the cause (or one of
it's parents) is annotated as a WebFault, a SOAP Fault containing the
correct webfault is formatted and sent and the client receives the
correct checked exception type as a result.

If not, it formats a default SOAP Fault with the message of the exception.
So the client receives a generic SOAPFaultException.

If I use CXF as a standalone server without OpenEJB, my exception is
correctly catched in the WebFaultOutInterceptor and as it is @WebFault
anotated, formats the corresponding soap fault.

In OpenEJB, when the exception appears on the server, the Stateless
container catches it, processes it  and chains it to the transaction
manager which in the end throws a new ApplicationException with my
exception as a cause.
But what the WebFaultOutInterceptor receives in this case is an
ApplicationException, which is NOT a @WebFault. So the interceptor
proceses this exception as a generic non-checked exception. Hence the
non typed exception on the client side...

Having realized that I tried to skip the new ApplicationException generation
by

1- marking my stateless webservice as nontransactional

@Stateless
@WebService(...)
@TransactionManagement(TransactionManagementType.BEAN)
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
class MyClass ...

2 - marking my exception as @ApplicationException

as it was my understanding of the specifications that
@ApplicationException should be re-thrown by the container as-is...

both actions where desperately useless...

So what can I do to have my server sending checked types ?

Thanks anyway for the time you will spend on that problem.
-- 
View this message in context: http://www.nabble.com/exceptions-handling-with-Webservices-tp19668275p19668275.html
Sent from the OpenEJB User mailing list archive at Nabble.com.


Re: exceptions handling with Webservices

Posted by uglything <ju...@gmail.com>.
Replying to myself...

As a "workaround", I defined a dumb @HandlerChain (the dumbest possible...
returns true to everything and an empty set for the headers) and my webfault
started magically to be processed as expected.
Bug or feature ???

Unfortunately, I have no time right now to look more thouroughly into the
code of OpenEJB to see exactly what happened. But I definitively will as
this seems to be too magic to me...

To make my point clearer, I join a Maven/Eclipse project of a simple case
that emphasises this.

http://www.nabble.com/file/p19747196/FunnyFault.zip FunnyFault.zip 

I hope that somebody can come with an explanation...

Thanks anyway for your great work on OpenEJB !

Regards,
Juan Manuel



uglything wrote:
> 
> Hie.
> 
> Here is my problem :
> 
> I have a webservice defined in an OpenEJB server (embedded CXF and
> JAXB-WS)
> 
> This webservice declares a method that throws a checked exception that
> is declared as a @WebFault.
> 
> When the client calls the server and when the webmethod sends an
> exception, the client receives a generic SoapFaultException with an
> ApplicationException inside.
> I expected my client to receive my business checked exception...
> 
> After having investigated a little bit, it appears that the
> WebFaultOutInterceptor class in the bundled CXF version works as
> follow :
> 
> When a fault is generated, it gets the cause. If the cause (or one of
> it's parents) is annotated as a WebFault, a SOAP Fault containing the
> correct webfault is formatted and sent and the client receives the
> correct checked exception type as a result.
> 
> If not, it formats a default SOAP Fault with the message of the exception.
> So the client receives a generic SOAPFaultException.
> 
> If I use CXF as a standalone server without OpenEJB, my exception is
> correctly catched in the WebFaultOutInterceptor and as it is @WebFault
> anotated, formats the corresponding soap fault.
> 
> In OpenEJB, when the exception appears on the server, the Stateless
> container catches it, processes it  and chains it to the transaction
> manager which in the end throws a new ApplicationException with my
> exception as a cause.
> But what the WebFaultOutInterceptor receives in this case is an
> ApplicationException, which is NOT a @WebFault. So the interceptor
> proceses this exception as a generic non-checked exception. Hence the
> non typed exception on the client side...
> 
> Having realized that I tried to skip the new ApplicationException
> generation by
> 
> 1- marking my stateless webservice as nontransactional
> 
> @Stateless
> @WebService(...)
> @TransactionManagement(TransactionManagementType.BEAN)
> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> class MyClass ...
> 
> 2 - marking my exception as @ApplicationException
> 
> as it was my understanding of the specifications that
> @ApplicationException should be re-thrown by the container as-is...
> 
> both actions where desperately useless...
> 
> So what can I do to have my server sending checked types ?
> 
> Thanks anyway for the time you will spend on that problem.
> 

-- 
View this message in context: http://www.nabble.com/exceptions-handling-with-Webservices-tp19668275p19747196.html
Sent from the OpenEJB User mailing list archive at Nabble.com.