cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Resolved] (CXF-6368) Unexpected response code
Date Fri, 24 Apr 2015 10:07:38 GMT


Sergey Beryozkin resolved CXF-6368.
       Resolution: Fixed
    Fix Version/s: 3.0.5
         Assignee: Sergey Beryozkin

Thanks for the analysis, JAXRSDefaultFaultOutInterceptor is meant to support non-JAXRS (CXF-specific)
interceptors that may throw the exceptions but users have registered JAX-RS Exception mappers.
In this case it is interfering with the JAX-RS flow - so I've updated the code for this interceptor
skip its processing in case of the unmapped second-time exceptions thrown from JAX-RS filters/interceptors

> Unexpected response code
> ------------------------
>                 Key: CXF-6368
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.0.3
>            Reporter: Wei Zhang
>            Assignee: Sergey Beryozkin
>             Fix For: 3.1.0, 3.0.5
> Come from a TCK test: 
> The excepted response code was 500, but got 200.
> The application is like this:
> Throw a RuntimeException from a ContainerResponseFilter
> public class CustomFilter implements ContainerResponseFilter {
> 	@Override
> 	public void filter(ContainerRequestContext requestContext,
> 			ContainerResponseContext responseContext) throws IOException {
>         		throw new RuntimeException("exception From custom ContainerResponseFilter");
> 		}
> 	}
> }
> A RuntimeExceptionMapper mapped the exception and set response code to 200.
> @Provider
> public class RuntimeExceptionMapper implements ExceptionMapper<RuntimeException>
> 	@Override
> 	public Response toResponse(RuntimeException exception) {
> 		return Response.ok(message).build();
> 	}
> }
> The filter was called first time, throw the exception, exception mapper mapped it. 
> When running method serializeMessage() in JAXRSOutInterceptor, the filer was called the
second time, throw the exception again. In method handleWriteException() of JAXRSOutInterceptor,
becasue firstTry=false, the exception was not mapped this time, setResponseStatus() was called.
> In JAXRSDefaultFaultOutInterceptor, the method JAXRSUtils.convertFaultToResponse() was
called,  the exception was mapped again. Then in method serializeMessage(), the filter was
called the third time. RuntimeExceptionMapper mapped again. Then method serializeMessage()
was called again, then the filter was called the fourth time, throw exception fourth time.
Becasue firstTry=false, the exception was not mapped this time, setResponseStatus() was called.
> Now in message, can found response status is 500. But later the response status 500 was
lost when set oldMessage back.

This message was sent by Atlassian JIRA

View raw message