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
