<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font size="-1">OK I am looking at ResourceMethodInvoker and
CompletionStageResponseConsumer and will work on a PR to support
other async types first. Should be the easiest. What you're
doing in </font><font size="-1"><font size="-1">CompletionStageResponseConsumer</font>
looks _a lot_ like what I had to do to support it myself in my
proto. Except the bit where I have to change the
jaxrsResponse.setGenericType because otherwise I get
CompletionStage<X>.class instead of X.class when I'm
looking up marshallers. Since it appears you do test this, I
assume it's somewhere else?</font><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/08/17 19:18, Ron Sigal wrote:<br>
</div>
<blockquote
cite="mid:351f61f7-cb11-5d14-6fe3-4e8678d809a8@redhat.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:resteasy-dev@lists.jboss.org">resteasy-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
<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>
</body>
</html>