tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From uglything <juanma.cabr...@gmail.com>
Subject Re: exceptions handling with Webservices
Date Tue, 30 Sep 2008 17:52:07 GMT

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.


Mime
View raw message