cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: Questions regarding JAX-RS exception handling
Date Mon, 21 Dec 2009 17:54:44 GMT
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


> 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


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

cheers, Sergey

> Cyrille
> --
> Cyrille Le Clerc

View raw message