Hello all, Here is a proposal of refactoring of both the JAXRS client-side and server-side, these refactoring could be separated one from the other.
Please, let me know if it worth continuing this work. SERVER SIDE ============ Move the ExceptionMapper handling from the JAXRSInvoker to a new JAXRSFaultOutInterceptor. Description : If an exception is associated with a Response via an ExceptionMapper, the fault interceptors chain is aborted and a new chain is triggered to render the Response. Pros : consistency between the JAXRS and JAXWS interceptor chains, for example, the ResponseTimeFeature can now count exceptions mapped to responses. Cons : a third interceptors chain is introduced for exceptions that are mapped to Response. It is a bit weird :-) CLIENT SIDE =========== Extract the marshalling and exception processing logic from the jaxrs client to interceptors ; I only worked on the ClientProxyImpl, the work on the WebClient is still to do. Description : * the JAXRSResponseInterceptor builds the Response object (currently with the inputstream object). Remaining : complete the Response processing with the unmarshalling of the inputstream * the JAXRSCheckFaultInterceptor handles faults and the ResponseExceptionMapper processing Pros : consistency betwen JAXRS and JAXWS interceptor chains, for example, the ResponseTimeFeature can now count exceptions mapped to responses. Cons : I didn't find any :-) Todo : complete the cleanup of the client Note : the ClientFaultConverter should NOT be declared as an "In Fault Interceptor" for JAXRS endpoints (specially important for the client) as the ClientFaultConverter tries to unmarshall a SOAP XML exception. Cyrille -- Cyrille Le Clerc clecl...@xebia.fr http://blog.xebia.fr On Mon, Dec 21, 2009 at 6:54 PM, Sergey Beryozkin <sbery...@progress.com> wrote: > > Hi Cyrille > > Please see comments inline > >> >> Dear all, >> >> I am looking at the consistency of exception handling among JAX-WS >> and JAX-RS. My primary goal is to ensure cxf management metrics (JMX) >> are consistent. >> >> Here are few questions : >> >> SERVER SIDE JAXRS EXCEPTION MAPPER >> ==================================== >> >> If an ExceptionMapper handles the exception : >> >> 1) The JAXRSInvoker returns a Response instead of throwing an Exception > > Yes, this is for JAXRS message body writers be able to handle whatever > Response entity a given mapper might've set up. > >> >> 2) Thus PhaseInterceptorChain does NOT see that an exception occurred >> during the invocation > > Yes > >> >> 3) Thus the "Out Interceptors" are not replaced by the "Out Fault >> Interceptors" and these "Out Interceptors" are called on >> #handleMessage() with the outMessage (ie the response created by the >> ExceptionMapper) instead of being called on #handleFaultMessage() with >> the inMessage when information like the FaultMode is still holded by >> the inMessage > > Yes > >> >> 4) Interceptors like the ResponseTimeMessageOutInterceptor who rely on >> the faultMode attribute located on the Message that is being passed to >> handleMessage/handleFault are lost, they don't find the information >> they look for > > I see... > >> >> Questions : >> * Wouldn't it make sense to call the "Out Fault Interceptors" if a >> JAX-RS exception is mapped to a custom response ? > > Now that you suggested it, perhaps, one alternative in mapping exceptions to > exception mappers would be to > register JAX-RS specific fault interceptors which will do the mapping, > instead of doing it in the JAXRSInInterceptor or JAXRSInvoker... > So other registered fault interceptors will get their chance as well... > > What complicates things a bit is that JAXRS users can have ResponseHandler > filteres registered which can override the ExceptionMapper responses... > >> * which message should be given to the handleFaultMessage() ? The >> inMessage that caused the exception and that holds the exception as an >> attribute (it would be consistent with JAX-WS) or the outMessage as >> currently done ? > > Perhaps we should consider introducing JAXRS fault interceptors ? They will > do Exception Mapping and abort the chain if the mapping has been found ? I'm > not yet sure how feasible and/or sensitive such a change might be, but may be > it will be the right step forward > >> >> CLIENT SIDE JAXRS EXCEPTION HANDLING >> ============================================= >> >> ClientProxyImpl handles exceptions after calling the interceptors >> when, with JAX-WS, exception handling (CheckFaultInterceptor) is >> performed in the POST_PROTOCOL phase. >> >> Due to this, the "In Interceptors Chain" is called instead of the "In >> Fault Interceptors Chain" and interceptors like >> ResponseTimeMessageInInterceptor don't see the Response as an >> exception. >> >> Question : >> Can we imagine to refactor jaxrs client side exception handling as a >> post protocol interceptor ? > > The client side needs some refactoring going forward....Some of its code > would definitely need to be moved to some isolated interceptors. However, > please see JAXRSSoapBookTest, Eamonn did quite a few tests with faulty > features/interceptors/server faults... > >> >> >> I hope this email was not too long ; it took me few hours to check all >> these use cases and figure out how it worked :-) > > No problems :-), please type as long a message as you'd like to :-), thanks > for starting this thread > > cheers, Sergey > >> >> Cyrille >> -- >> Cyrille Le Clerc >> clecl...@xebia.fr >
