[
https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15651554#comment-15651554
]
Sergey Beryozkin commented on CXF-7119:
---------------------------------------
Can you please get back to me and explain why catching ProcessingException and
get its IOException cause is not ideal in your case ? The only other
alternative that I can see is to return a custom RuntimeException instead - is
it what you are after ?
> ResponseExceptionMapper not used for technical exceptions (e.g. IOException)
> ----------------------------------------------------------------------------
>
> Key: CXF-7119
> URL: https://issues.apache.org/jira/browse/CXF-7119
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.1.3
> Reporter: Jörg Hohwiller
>
> When using CXF for REST/JAX-RS service clients I quickly noticed that I need
> to tweak the error handling. My services use an ExceptionMapper that provides
> error details via JSON result payload. Hence I want to access this and render
> an exception with further details and more context information what works
> fine with ResponseExceptionMapper.
> However, when a technical error (IOException such as unkown host, connection
> refused, timeout, etc.) occurrs I only get generic errors from CXF client
> (org.apache.cxf.interceptor.Fault: Could not send Message.). This is
> undesired but unfortunately my custom ResponseExceptionMapper is never called
> for such technical errors. There seems to be no way to archive my goal with
> CXF itself. I could only wrap the client again with a custom written dynamic
> proxy to reach my goal.
> It seems that CXF hardwires this behaviour:
> https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64
> It would be awesome if in such case ResponseExceptionMapper would also be
> applied so I have the chance to interfere and produce better exceptions (e.g.
> with a message containing the name of the application/microservice that could
> not be called, the URL, etc.) for my individual needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
