[
https://issues.apache.org/jira/browse/CXF-7989?focusedWorklogId=215178&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-215178
]
ASF GitHub Bot logged work on CXF-7989:
---------------------------------------
Author: ASF GitHub Bot
Created on: 19/Mar/19 02:11
Start Date: 19/Mar/19 02:11
Worklog Time Spent: 10m
Work Description: reta commented on pull request #526: CXF-7989:
org.apache.cxf.jaxrs.JAXRSInvoker should handle CompletionException
URL: https://github.com/apache/cxf/pull/526
The Problem
===
In case when CXF is used along with `CompletionStage` / `CompletableFuture`,
in most cases the error handling is propagated back through
`CompletionException` instance
(http://cs.oswego.edu/pipermail/concurrency-interest/2014-August/012911.html).
It works but it forces users to introduce own implementations of
`ExceptionMapper`s and manually unwrap the `CompletionException` into something
more meaningful.
Use cases
===
There are 3 leading use cases which cover most typical usage of the
`CompletionStage` / `CompletableFuture`.
1. `@Suspended AsyncResponse`
```
public void get(@PathParam("isbn") String isbn, @Suspended final
AsyncResponse resp) {
client.target("http://localhost:19092/services/catalog/"; + isbn)
.request()
.rx()
.get(Book.class)
.whenComplete((r, ex) -> {
if (ex != null) {
resp.resume(ex);
} else {
resp.resume(r);
}
});
}
```
2. Return `CompletableFuture<Book>`
```
public CompletableFuture<Book> get(@PathParam("isbn") String isbn) {
return client
.target("http://localhost:19092/services/catalog/"; + isbn)
.request()
.rx()
.get(Book.class)
.toCompletableFuture();
}
```
3. Return constructed instance of the `CompletableFuture<Book>`
```
public CompletableFuture<Book> get(@PathParam("isbn") String isbn) {
final CompletableFuture<Book> future = new CompletableFuture<Book>();
future.completeExceptionally(...);
return future;
}
```
Suggested Solution
===
Instrument `JAXRSInvoker::handleAsyncResponse` to distinguish
`CompletionException`, unwrap the cause and use it to select the appropriate
`ExceptionMapper` (if any).
@rmannibucau why `JAXRSInvoker::handleAsyncResponse` and not
`JAXRSInvoker::checkFutureResponse`, the 1st use case which uses suspended
async response does not flow through `JAXRSInvoker::checkFutureResponse` but
all three use cases run through `JAXRSInvoker::handleAsyncResponse`
@coheigea @dkulp guys would really appreciate if you could take a quick
look, small change but may introduce undesired side effects, thanks a lot.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 215178)
Time Spent: 10m
Remaining Estimate: 0h
> org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle
> CompletionException
> ------------------------------------------------------------------------------------------------
>
> Key: CXF-7989
> URL: https://issues.apache.org/jira/browse/CXF-7989
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Affects Versions: 3.3.0
> Reporter: Romain Manni-Bucau
> Assignee: Andriy Redko
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The check should probably unwrap CompletionException otherwise it can require
> some more custom ExceptionMappers to achieve a correct behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
