Il 04/04/2017 17:17, Sergey Beryozkin ha scritto:
> Would it make sense to return to what was available in m01, what
> Santiago originally prototyped, and restrict to the server code only ?
>
> It would be a basic NIO support, without being too involved, yet it
> would allow JAX-RS users to tap into Servlet 3.1 NIO API.
> Future JAX-RS 3.0 (?) based on Java 9 will be Java 9 Flow/etc based
> which will be good, but it will be many years before it will happen.
> In meantime users would use a somewhat limited but yet functional
> server side NIO which will become a 'legacy' API in future JAX-RSs.
>
> IMHO it will be better than having no NIO at all
+1, a simple NIO support for now looks like a good idea to me too.
It's possibly too early to put the more advanced solution into the spec;
while I see the point on having something ready for the future (and I'm
sorry I'm coming late to effectively contribute on the that effort), I
think it also makes sense for the spec to consolidate over a more
advanced solution in a future version, perhaps once such solution has
shipped as custom extension in one (or more) JAX-RS implementation(s)
and has been used / verified in the field.
Cheers
Alessio
>
> Sergey
>
>
> On 04/04/17 14:49, Sergey Beryozkin wrote:
>> Hi Pavel
>>
>> It's disappointing even though I appreciate the effort done so far.
>> Probably the most important feature we could've done and now we will
>> face +N (or more) years of waiting for JAX-RS be NIO ready, and by
>> the time it will happen everyone will already be using Spring RS
>> anyway who are charging ahead as we speak with top-class Reactive
>> support...
>> I don't know, we will have though SSE which not all browser
>> implement, I'd rather have only NIO instead of SSE.
>> The 'Flow' duplication argument is not convincing because I believe
>> you had a plan after all to get rid of it when we get to Java 9.
>> The mid of April constraints just highlights that the process once
>> again defeats us completing the work which was planned
>>
>> Thanks, Sergey
>>
>> On 03/04/17 17:40, Pavel Bucek wrote:
>>>
>>> Dear EG members,
>>>
>>> As you all know we have been hard at work trying to come up with an
>>> NIO proposal based on Flows. In doing so, we have come to the
>>> conclusion that this is indeed a really hard problem --lots of small
>>> details that need double clicking! After some deliberation, we have
>>> come to the conclusion that it is better to drop this feature from
>>> this dot release. Here is the rationale for doing so:
>>>
>>> - Working backwards from the officially committed Java EE 8 release
>>> date - July 2017 - we need to start Public Review in the middle of
>>> April, which means that at this point we don't have enough time to
>>> do a design, implementation prototype and gather appropriate feedback.
>>> - Current proposal is based on a Flow-like API, which would force us
>>> to duplicate the JDK 9 Flow concept in the JAX-RS 2.1 API.
>>> - We don't want to introduce "just another non-blocking API", which
>>> might be deprecated very soon (when Java 9 is released).
>>> - We need some time to work on "smaller issues", which would be most
>>> likely not possible if we'll continue working on NIO.
>>>
>>> *What does that mean for the current state of the API?*
>>>
>>> We will remove Flow.* interfaces and its usage in existing APIs,
>>> which means adjustments in SSE part of the spec. Also, we will be
>>> making at least some improvement, more related to already introduced
>>> Reactive API - support for returning CompletionStage from the
>>> resource method. It was in our last version of the high level
>>> non-blocking API; CompletionStage is basically a Mono - publisher of
>>> a single item. Resource method could then look like:
>>>
>>> @POST @Path("acceptProduceSource")
>>> public CompletionStage<AnotherPOJO> echoNioEntity(POJO requestEntity) {
>>>
>>> // not blocking the thread, returning CompletionStage and doing the
>>> work elsewhere. return ...;
>>>
>>> }
>>>
>>> This improvement will simplify use of the new JAX-RS 2.1 reactive
>>> client API in a JAX-RS resource method. Note that this is already
>>> tracked as https://java.net/jira/browse/JAX_RS_SPEC-546.
>>>
>>> As always, any comments or suggestions are appreciated.
>>>
>>> Thanks and regards,
>>> Pavel & Santiago
>>>
>>
>