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.
