[
https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696282#comment-15696282
]
Sergey Beryozkin commented on CXF-7119:
---------------------------------------
Both approaches give the user a full control but I agree the latter option is
less attractive for the proxy users.
But the other question is the consistency with respect to processing the
client technical exceptions for both Proxy and HTTP Centric JAX-RS clients
(JAX-RS 2.0 clients, CXF WebClient). HTTP centric clients will throw
ProcessingException and if Proxy throws ProcessingException (and this is
something the users may already have written the code around) the we can have:
{code:java}
MyProxy proxy = createProxy();
try {
useProxy(proxy);
} catch (ProcessingException ex) {
handleException(ex.getCause());
}
WebTarget web = createJAXRS20WebTarget();
try {
useWebTarget(web);
} catch (ProcessingException ex) {
handleException(ex.getCause());
}
// reused by the proxy and web target code
private void handleException(Throwable t) {
}
{code}
And as I already noted proxies have been wrapping the exceptions into
ProcessingException for a while so I can not change that by default.
But what I can do is to introduce a property which your fault in interceptors
can set and which will let the client code avoid wrapping the runtime
exceptions.
> Introduce a JAX-RS client provider for catching technical exceptions (e.g.
> IOException)
> ---------------------------------------------------------------------------------------
>
> Key: CXF-7119
> URL: https://issues.apache.org/jira/browse/CXF-7119
> Project: CXF
> Issue Type: New Feature
> Components: JAX-RS
> Affects Versions: 3.1.3
> Reporter: Jörg Hohwiller
> Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.9
>
>
> 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)
