cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyrille Le Clerc <>
Subject Re: Questions regarding JAX-RS exception handling
Date Mon, 28 Dec 2009 17:16:30 GMT
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.


Move the ExceptionMapper handling from the JAXRSInvoker to a new

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

Cons : a third interceptors chain is introduced for exceptions that
are mapped to Response. It is a bit weird :-)


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

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 Le Clerc

On Mon, Dec 21, 2009 at 6:54 PM, Sergey Beryozkin <> 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 :
>> ====================================
>> 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
>> =============================================
>> 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

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message