Hi Mandy
On 30/11/13 18:49, Mandy Warren wrote:
Hi,
I just installed 2.7.8 today and realised that when I tested the fix below, I
only tested it using an Interceptor which ran after JAXRSInInterceptor ie:
super(Phase.UNMARSHAL);
getAfter().add(JAXRSInInterceptor.class.getName());
I've created a few more interceptors since including some that run at the
Phase.RECEIVE. Looking at the documentation
(http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-MappingexceptionsthrownfromCXFinterceptors
) you do clearly start that
only interceptors which are registered after JAXRSInInterceptor
(Phase.UNMARSHAL) and out interceptors registered before JAXRSOutInterceptor
(Phase.MARSHAL) are supported. Are there any plans to support handling
exceptions via an exception mapper from earlier / later in the
chain?
Yes, it actually has been implemented correctly on the trunk, in fact I
did it last Friday.
Unfortunately I was not able to merge to 2.7.9-SNAPSHOT, the fix I made
on the trunk had been made possible after Dan's refactoring effort, with
JAX-RS frontend having its own CXF Binding implementation on the trunk.
In CXF 2.7.x it depends on XML Binding which sets StaxOutInterceptor on
the fault chain by default, this prevents the JAX-RS exception mapping
done in the fault interceptor.
FYI, JAXRSOutExceptionMapperInterceptor has been deprecated too on the
trunk, it is just much cleaner now on the trunk with respect to mapping
native CXF exceptions with JAX-RS mappers. I stopped short of completely
removing it knowing that several people may be using it now.
In meantime, in 2.7.x, if you need to map the exceptions thrown from
interceptors running before JAXRSInInterceptor then you can do it with a
custom out fault interceptor, the only restriction there is that if a
text needs to be produced too then it can only be in XML format
Re interceptors running after JAXRSOutInterceptor, such faults will me
mapped to now on the trunk (and with a custom fault out interceptor if
needed) but I'm not sure it can be effective because JAXRSOutInterceptor
will actually end up writing the data to the output stream.
Splitting JAXRSOutInterceptor is tricky because per the spec, if JAX-RS
Message Body Writer throws an exception and if it can be mapped then the
whole JAX-RS out chain needs to be rerun once (example, filters will run
again, etc).
There might be a scope for some *optional* optimizations, example, if we
know that XML is being produced then we can create a Stax writer and let
the Stax ending interceptor finish it at the end of the chain, with
custom interceptors updating the output in between, but it's going to be
a sensitive refactoring, I'll try to review what can be realistically
done in this regard in the next major CXF release
Thanks, Sergey
Many thanks
Mandy
Sent from a mobile device
On 7 Oct 2013, at 11:23, Sergey Beryozkin <[email protected]> wrote:
Hi Mandy
On 06/10/13 22:11, Mandy Warren wrote:
Hi Sergey,
I finally got round to testing this tonight for handling both In & Out Interceptor
faults & it works perfectly as described using 2.7.8-SNAPSHOT. This makes life so
much easier!
Sounds good, thanks for testing the latest code
Do you have any rough timescale as to when 2.7.8 will be released?
I'm not sure, we may be able to do a 3.0 RC in a few weeks or so, 2.7.8 release
might be considered too, but I'm not sure yet
Thanks, Sergey
Many thanks
Mandy
On 1 Oct 2013, at 13:23, Sergey Beryozkin wrote:
I've actually merged it to CXF 2.7.x, but made the in fault mapping optional so
as not to affect the existing in fault interceptors if any:
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Basics#JAX-RSBasics-MappingexceptionsthrownfromCXFinterceptors
Cheers, Sergey
On 28/09/13 21:28, Mandy Warren wrote:
This is great news Sergey, thanks so much for following this up! Please let me
know when this is ready to use!
Mandy
Sent from a mobile device
On 25 Sep 2013, at 21:28, Sergey Beryozkin <[email protected]> wrote:
Hi Mandy,
FYI, after talking to you I thought I'd go ahead and finally resolve the long
time pending issue of mapping the exceptions thrown from non-JAX-RS CXF
interceptors to JAX-RS responses. I think it is mostly done now, after chatting
to Dan and poking a bit it seems to be working OK, but on the trunk only, I may
need to tweak it a bit more before documenting.
So if the exceptions can be mapped by ExceptionMappers then they won't make it
to the fault chain where the mapping would have to be done manually - I'm
keeping this change on the trunk as there could be the existing fault
interceptors deployed but the good news is that it will become simpler to
manage the exceptions thrown from the existing CXF interceptors on JAX-RS
runtime paths...
Thanks, Sergey
On 19/09/13 21:31, Mandy Warren wrote:
Many thanks this worked fine!
Sent from a mobile device
On 13 Sep 2013, at 17:31, Sergey Beryozkin <[email protected]> wrote:
Hi
On 13/09/13 12:35, Mandy Warren wrote:
Many thanks for your reply. I am now using an ExceptionMapper for application
errors and have created a ResponseHandler to try an catch other interceptor
exceptions but I can't work out how to get hold of the exception from the
objects passed into the handleResponse method.
I tried doing
message.getExchange().getOutMessage().getContent(Exception.class)) but no luck..
Please could you advise how this is possible?
The problem is that the exceptions thrown from the CXF interceptors escape the
JAX-RS flow, ResponseHandler (or ContainerResponseFilter in CXF 3.0.0 SNAPSHOT)
are part of the normal out JAX-RS chain and they do not see those exceptions.
I'm presuming you throw the exceptions from CXF in interceptors, right ?
Try replacing them with RequestHandler (or ContainerRequestFilter if on CXF
2.7.x)
I need to check if, optionally, we can handle the exceptions coming from other
CXF in interceptors via JAX-RS and effectively ignore or fault out chain...
Cheers, Sergey
Many thanks
Sent from a mobile device
On 12 Sep 2013, at 21:05, Sergey Beryozkin <[email protected]> wrote:
Hi
On 12/09/13 18:32, Mandy Warren wrote:
Hi,
I am trying to write a Fault Interceptor to handle exceptions both from my
application code & from other interceptors. The Interceptor needs to change
the HTTP status code to something appropriate and set the message body with
info that explains the error in more detail (either in JSON or XML
depending on the request mime type).
Many of the examples I have seen modify the HttpResponse using code such as:
HttpServletResponse response = (HttpServletResponse) message
.getExchange().getInMessage()
.get(AbstractHTTPDestination.HTTP_RESPONSE);
however because we have integration tests which use the CXF local transport
rather than HTTP this code doesn't seem to work.
I need a solution which works for both HTTP & Local Transport.
Here's the code I have so far but I get a null pointer thrown as the
OutMessage seems to be null..
public class MyFaultInterceptor extends AbstractPhaseInterceptor<Message> {
public CAPTWOFaultInterceptor() {
super(Phase.PRE_STREAM);
}
public void handleMessage(Message message) throws Fault {
Exception ex = message.getContent(Exception.class);
if (ex == null) {
LOGGER.debug("unexpected null exception");
throw new RuntimeException("Exception is expected");
}
if (!(ex instanceof Fault)) {
LOGGER.debug("unexpected exception type");
throw new RuntimeException("Fault is expected");
}
Fault fault = (Fault)ex;
Throwable causingException = fault.getCause();
LOGGER.debug("handling exception
{}"+causingException.getClass().getName());
if (causingException instanceof SomeBadException) {
Response response =
Response.status(Response.Status.INTERNAL_SERVER_ERROR).build();
// outMessage seems to be null!
message.getExchange().getOutMessage().put(Response.class,
response);
}
message.getInterceptorChain().abort(); // not sure if I need this!
}
Any help would be much appreciated!
I think the only way to make it work in a portable way across multiple
transports is to work with JAX-RS 2.0 ExceptionMapper (for catching the
exceptions) and also replace the CXF interceptors with JAX-RS 2.0 in/out
filters - this way it is guaranteed that JAX-RS Response will be produced and
thus it will work even for Local transport.
Using CXF interceptors in JAX-RS would also work with Local transport in normal
flows but the exceptions thrown from such interceptors can only be handled in
fault interceptors, where realistically you need to work with
HttpServletResponse;
I'm not sure why an out message is null; that solution probably won't work
anyway, though may be we should look into it too; I'm not sure actually we have
Local transport tests dealing with JAX-RS server errors, I'll have a look
Sergey
Many thanks
Mandy
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
