<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><font size="-1">Well, I guess that can't be that part. I'm
        talking about a resource method returning an entity of type
        CompletionStage&lt;X&gt;, and where we look up marshallers for X
        and not CompletionStage&lt;X&gt;. In
        CompletionStageResponseConsumer you do:</font></p>
    <p><font size="-1">        
        jaxrsResponse.setGenericType(method.getGenericReturnType());<br>
      </font></p>
    <p>Which can't be right, unless method.getGenericReturnType() is
      already unwrapped to X and not CompletionStage&lt;X&gt;, but I
      haven't found where. Or is this unwrapped later?<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 23/08/17 23:24, Ron Sigal wrote:<br>
    </div>
    <blockquote
      cite="mid:a0d318f8-43a1-2158-bb8b-1a529dfb6387@redhat.com"
      type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <p>Hi Stephane,</p>
      <p>It looks like I missed this email - I was on PTO on 8/11. Are
        you referring to</p>
      <p> </p>
      <blockquote type="cite">      else if (entity instanceof Response)<br>
              {<br>
                 Response r = (Response) entity;<br>
                 Headers&lt;Object&gt; metadata = new
        Headers&lt;Object&gt;();<br>
                 metadata.putAll(r.getMetadata());<br>
                 builtResponse = new BuiltResponse(r.getStatus(),
        r.getStatusInfo().getReasonPhrase(), metadata, r.getEntity(), 
        method.getMethodAnnotations());<br>
              }</blockquote>
      <p>in
org.jboss.resteasy.core.CompletionStageResponseConsumer.createResponse()?
        Is this still an issue?</p>
      <p>-Ron<br>
      </p>
      <br>
      <div class="moz-cite-prefix">On 08/11/2017 08:12 AM, Stephane
        Epardaud wrote:<br>
      </div>
      <blockquote
        cite="mid:7736a5d2-4bf5-fe1a-7e92-1a54c2e8d659@epardaud.fr"
        type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        <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&lt;X&gt;.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&lt;Response&gt;. 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&lt;X&gt;
                (or rx.Single&lt;X&gt; 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&lt;Object&gt; because Java doesn't have
                Union Types and I can't declare it as
                CompletionStage&lt;Response | MyEntity&gt;, 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&lt;X&gt;, 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&lt;? extends
                ExceptionMapper&gt;) 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 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>
        <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>