<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Stephane,</p>
<p>Wow, that's a lot to digest. ;-)</p>
<p>Have you seen the treatment of CompletionStage in
org.jboss.resteasy.core.ResourceMethodInvoker. If the resource
method return type is CompletionStage, ResourceMethodInvoker
registers a
org.jboss.resteasy.core.CompletionStageResponseConsumer that waits
for a response. CompletionStage is hard coded here, but maybe we
could use service loading and a ContextResolver to get a method
that <br>
</p>
1. verifies that a given class has asynchronous behavior, and<br>
2. constructs an appropriate object like
CompletionStageResponseConsumer to listen for a completed response.<br>
<br>
<p>I'll go on to try to digest the rest of your message, but that's
a start, I hope.</p>
<p>-Ron<br>
</p>
<br>
<div class="moz-cite-prefix">On 08/10/2017 03:38 AM, Stephane
Epardaud wrote:<br>
</div>
<blockquote
cite="mid:d26ef41e-5b1e-58b0-fc55-274384b7969f@epardaud.fr"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div class="moz-text-html" lang="x-unicode"> <font size="-1">Hi,<br>
<br>
I'm working on trying to make Resteasy and Vertx integrate
better, and while writing a prototype I noticed several things
which would need support from Resteasy.<br>
<br>
The first thing which I need RE to support is that I want to
be able to return async types from my resource methods. In
JAX-RS 2.0 async resource methods are supported but require a
peculiar style, such as taking a "@Suspended AsyncResponse
asyncResponse" parameter, returning void, and resuming with
asyncResponse.resume(entityOrException).<br>
<br>
I know JAX-RS 2.1 supports CompletionStage<Response>.
This is great, but it doesn't define a pluggable API to
support other types such as rxJava. We should really make that
be pluggable, so that I can use rx.Single or other async
frameworks.<br>
<br>
ATM I have a prototype which supports CompletionStage and
rx.Single, without modifying RE, but it's using CDI validators
to intercept the returned value and do the plugging, which is
a terrible hack. I couldn't find a way to do this properly
with RE because I can't intercept the returned value before
it's sent to the marshallers, by which time it's too late to
mark the response as async and register on the listeners.<br>
<br>
Now, because the return type is CompletionStage<X> (or
rx.Single<X> doesn't matter), the
ResourceMethodInvoker.getGenericReturnType() returns a very
unhelpful type, which I can't used to look up the proper
marshallers, so again this is something that has to be taken
into account. <br>
<br>
Sometimes I will declare a return type of
CompletionStage<Object> because Java doesn't have Union
Types and I can't declare it as CompletionStage<Response |
MyEntity>, and in that case I have to look up marshallers
based on the entity instance's class rather than the declared
type. I suppose the same applies to non-async return types. Is
it the spec that fixes this looking up of marshallers based on
the static return type and not the entity's actual type?<br>
<br>
Now, I haven't said much about things like Observable or
Flowable (async types that emit more than one value), because
it's not yet clear in my mind how that would work with RE. In
my proto I do support returning such flows and based on how
the method is annotated, RE will pick one strategy:<br>
<br>
- collect all values in a java.util.List and when all done
proceed,<br>
- send them as HTTP Chunked: marshall and send each value as
they are made available<br>
- send them as server-sent events but that's a bit weird when
it's not plain text<br>
<br>
Since JAX-RS 2.1 supports server-sent events, that would also
be a strategy that makes sense.<br>
<br>
I have contacted the CDI team to discuss async injection,
because I also want to be able to inject instances of X in my
resources where there only exists providers of type
CompletionStage<X>, which requires a new CDI API to
support async resource instantiation/injection. If/when that
gets added to CDI, RE will need to be updated to support this
async injection.<br>
<br>
Similarly I also have a problem with interceptors, because
sometimes my RE interceptors require resolving of async types
before they can go on with the request. For example for
authentication or sessions my interceptors have to wait for
vert.x to resolve async values before I can check them and
proceed with the requests. The wait the interceptor API is
written doesn't let me suspend interception. It's be great if
it could. Alternately CDI interceptors have an
InvocationContext parameter given to the interceptor on which
you have to call proceed() in order to proceed. This allows me
to delay proceeding until I have all my async values resolved
and only then proceed with the call to the next interceptor.
That'd work too.<br>
<br>
And I guess the same applies to Marshallers. I have Template
entity objects that I need to marshall and that is done via an
async API in vertx, so again I can't entirely marshall the
response when the marshaller is called.<br>
<br>
Last, and least interestingly, I've always been bitten by the
fact that ExceptionMappers are global and I can't override
them per resource. Sometimes I have UI/HTML resources that
need exception mappers that forward to UI pages, and API
resources that have to serialise errors into JSON. I've added
support for an @WithExceptionMapper(Class<? extends
ExceptionMapper>) annotation that you can place on the
resource method or class to override the error mapper for this
call.<br>
<br>
WDYT?<br>
<br>
I'm definitly game for pushing PRs for those things, BTW.<br>
<br>
How far along are you guys with implementing JAX-RS 2.1 in RE?<br>
<br>
Cheers.<br>
</font> </div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
resteasy-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:resteasy-dev@lists.jboss.org">resteasy-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/resteasy-dev">https://lists.jboss.org/mailman/listinfo/resteasy-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
My company's smarter than your company (unless you work for Red Hat)</pre>
</body>
</html>