I forgot to add link to the commit:
https://github.com/jax-rs/api/commit/8c1c93d3ec29971cedac0d605e9fb95eb70717f8
On 07/04/2017 11:04, Pavel Bucek wrote:
>
> FYI: We just submitted a patch which removes Flow and uses of that.
>
> There were slight changes in the existing SSE Api, most of them were
> only cosmetic; we also had to add "send" method to the SseEventSink:
>
> /** * Send an outbound Server-sent event to this sink. * <p>* Event
> will be serialized and sent to the client. * * @param event event to
> be written. * @return completion stage that completes when the event
> has been sent. If there is a problem during sending of * an event,
> completion stage will be completed exceptionally. */ public CompletionStage<?> send(OutboundSseEvent event);
>
> And slightly modified SseBroadcaster#broadcast:
>
> /** * Publish an SSE event to all subscribed {_at_link SseEventSink}
> instances. * * @param event SSE event to be published. * @return
> completion stage that completes when the event has been broadcast to
> all registered event sinks. */ CompletionStage<?> broadcast(final OutboundSseEvent event);
>
> (returns Completion stage, to stay in sync with SseEventSink).
>
> The change looks as it is a big one, but it's mostly removing lots of
> code. We could have missed something, so feel free to post any
> comments / raise issues here or use bug tracker:
> https://java.net/jira/browse/JAX_RS_SPEC
>
> Thanks and regards,
> Pavel
>
>
> On 03/04/2017 18: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
>>
>