Closed Kiiv closed 5 months ago
jim-krueger
commented
5 months ago I believe what you are experiencing is expected behavior and that CXF intentionally does not log that exception, but maps it to the response. Are you now receiving any information about the exception in the response?
Kiiv
commented
5 months ago Nop, nothing about the original exception is sent in the response. I got only the response code and eventually the entity if I set one by myself in the Response object passed to the ForbiddenException.
jim-krueger
commented
5 months ago Please run with the following trace enabled and attach a zip of the server's logs directory: com.ibm.ws.jaxrs=all:com.ibm.websphere.jaxrs=all:org.apache.cxf.*=all
jim-krueger
commented
5 months ago Thanks. Can you please confirm that your client is receiving a Response with status code 403? Thanks
Kiiv
commented
5 months ago Yes, I confirm that my client receive a status code 403 as expected.
jim-krueger
commented
5 months ago Hi, After reviewing this and looking a bit in the code I have confirmed that this is functioning as designed.
See: CustomExceptionMapperRegister
customExceptionMapper.setPrintStackTrace(false); // set to 'false' to avoid printing response errors to Messages.log
This code sets the PrintStackTrace to false for Liberty's default CustomWebApplicationExceptionMapper.
You can work around this by creating your own custom exception mapper for WebApplicationExceptions. Something similar to:
@Provider
public class MyCustomExceptionMapper implements ExceptionMapper<WebApplicationException> {
public Response toResponse(WebApplicationException ex) {
ex.printStackTrace();
Response r = ex.getResponse();
return r;
}
}Hopefully this helps.
jim-krueger
commented
5 months ago Closing this issue. Please re-open if it requires additional attention.
Kiiv
commented
5 months ago Thanks for your detailed analysis !
I think I'll have to go for a custom WebApplicationExceptionMapper extending your own CustomWebApplicationExceptionMapper to not break your error code mapping.
Kiiv
commented
4 months ago Hi,
I come back to give feedback and discuss one more case.
So, as expected, I was able to add a log message for WebApplicationException by adding a custom ExceptionMapper for them.
Unfortunately, there is a case where the ExceptionMapper is not called. As stated in the Jax-rs specification, if the Response contained in the WebApplicationException already as an entity, the container must not call the ExceptionMapper :
Chapter 3.3.4 of the jax-rs 2.2.1 specification
Instances of WebApplicationException and its subclasses MUST be mapped to a response as follows. If the response property of the exception does not contain an entity and an exception mapping
provider (see Section 4.4) is available for WebApplicationException or the corresponding subclass, an implementation MUST use the provider to create a new Response instance, **otherwise the
response property is used directly**. The resulting Response instance is then processed according to
Section 3.3.3.In that case, I think I can't do anything on my own. It's probably working as expected but I'm very curious about the choice to not log this kind of exception.
Hi,
don't know if it's the right place to talk about that.
When I throw an Exception like IllegalArgumentException in my application, OpenLiberty log it (several times :p) as we could expect it :
But when I throw a WebApplicationException with a Response already set, OpenLiberty does not log anything. Using the same test code but replacing IllegalArgumentException by ForbiddenException, there no information logged by the application server.
I know that ExceptionMapper are not called if the exception already as a Response but I would expect the application server would be able to log this kind of error anyway. For now, there is no stack available to find where this kind of exception occurs.
Tested with a very simple Rest Resource :
Do I miss something or is it working as expected ?
Diagnostic information:
server.xml configuration (WITHOUT sensitive information like passwords)