users@jax-rs-spec.java.net

[jax-rs-spec users] Re: NIO API review / request for feedback

From: Pavel Bucek <pavel.bucek_at_oracle.com>
Date: Fri, 10 Mar 2017 11:53:34 +0100

Hi Sergey,

as always, thanks for your feedback!

Please see inline (I'm removing finished subthreads).


>>> 2. @Suspended should not be enforced - would that conflict with the
>>> idea of having an AsyncResponse helper method ?
>> Most likely yes. @Suspended should be always there, since JAX-RS
>> somewhere mentions that only resource method parameter without an
>> annotation is an entity. How would the implementation recognize that
>> AsyncResponse is not an entity? Also, it seem to make more sense to
>> pass the response to some process, which is producing the (request)
>> entity - compare that to passing reuqest entity publisher to async
>> response.
>
> I'm not sure if we are disagreeing here :-). As far as I understand,
> that yes, @Suspended will stay if we have a style where AsyncResponse
> is explicitly provided.
>
> But you also said, "Note that using @Suspended shouldn't be enforced
> here; it should be possible to return a Response directly and still be
> able to consume the *request* entity. ". May be you can clarify this
> statement with the code, did you mean:
>
> @POST @Path("/ex2")
> @Consumes(MediaType.APPLICATION_JSON)public Response ex2(Flow.Publisher<POJO> entity) {
> ?

sorry for the confusion. The remark was meant as
"javax.ws.rs.core.Response can still be returned from the resource
method if needed, but I don't believe that it does make sense (returning
a status without reading the whole entity)".

So the exact thing you expressed in the code.

>>> 3. NioBodyReader.isReadable type parameter - I'm not sure yet
>>> either; I also wonder about the mapping processors, for example, given
>>> // ex1 processor public static class Ex1Processorimplements Flow.Processor<ByteBuffer, ByteBuffer> {
>>>
>>> // ... }
>>> and
>>> // mapping Publisher<ByteBuffer> to Publisher<POJO> // ByteBuffers
>>> are expected to contain JSON (indicated by @Consumes on the resource
>>> method and NioBodyReader). public static class Ex2MappingProcessorimplements Flow.Subscriber<ByteBuffer>, Flow.Publisher<POJO> {
>>> // ... }
>>>
>>> why can't we have
>>>
>>> // mapping Publisher<ByteBuffer> to Publisher<POJO> // ByteBuffers
>>> are expected to contain JSON (indicated by @Consumes on the resource
>>> method and NioBodyReader). public static class Ex2MappingProcessorimplements Flow.Processor<ByteBuffer, POJO> {
>>> // ... }
>>>
>>> There's obviously a good reason for it but would like to understand
>>> the diiferences
>> I'm sorry to disappoint, but there is no good reason :) I guess I
>> wanted to not introduce dependency on the Processor when not needed,
>> but currently it is used in the Reader/WriterInterceptorContext and
>> Container(Request|Response)Context, so I could write it as you did.
>> Thanks, Pavel
>
> OK, I guess in a couple of weeks may be you can do m06, after the
> initial round is more or less complete, so that we can start playing
> with the API, would be easier to spot what works really well, what
> might be improved

That's what we are going to do in the meantime as well. I plan to play
with the implementation little bit more when thinking about current
proposal (and modifying it).

There will be a release for the EDR feedback, but as you mentioned, we
can certainly do more releases as "nio api checkpoints" when we have
enough changes and some proof that it can work.

thanks again and looking forward to any further feedback.
Pavel