cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
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 :
>
> 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
> cleclerc@xebia.fr 


Mime
View raw message