users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Server-Sent Events API proposal​ - update

From: Pavel Bucek <pavel.bucek_at_oracle.com>
Date: Fri, 10 Feb 2017 11:41:06 +0100

The last thing we want to do is to create some limitation which would
forbid JAX-RS implementation running outside of CDI/other container like
that :)

We really like lightweight runtimes like Jersey + Grizzly | Netty |
Jetty | anything, I'm sure other JAX-RS implementations do have similar
enhancements as well - don't take me wrong, I don't dislike CDI, but
when the application doesn't need it, we definitely don't want to force it.

Having said that - I don't mind your reaction. It could happen that we
introduce something like that by mistake and I'd rather get the feedback
and have a chance to fix it compared to finding that much later and
hoping it's not too late.

Anyway, since I have you on the line - I can release next JAX-RS
milestone by the end of today, I believe it is already overdue. We
obviously can change the code afterwards, but clearer is better - if you
(or anyone else) has any prompt feedback, I'll happily incorporate it so
it can be part of that milestone.

Best regards,
Pavel


On 10/02/2017 10:59, Sergey Beryozkin wrote:
> Hi Pavel
>
> Oh, that is great then, sounds good.
> In fact what you did is really good, my reaction was really about,
> 'will that work with non-CDI (in Spring Boot for ex), and other scary
> thoughts',
>
> Thanks for reacting to my over-reaction so nicely
>
> Cheers, Sergey
> On 10/02/17 09:59, Pavel Bucek wrote:
>>
>> Hi Sergey,
>>
>> @Inject is not a requirement. You still can inject with @Context, i.e.:
>>
>> public ItemStoreResource(@Context Sse sse) {
>> this.sse = sse;
>> this.broadcaster = sse.newBroadcaster();
>>
>> broadcaster.onException((sseEventOutput, e) ->
>> LOGGER.log(Level.WARNING,"An exception has been thrown while broadcasting to an event output.", e));
>>
>> broadcaster.onClose(sseEventOutput ->LOGGER.log(Level.INFO,"SSE event output has been closed."));
>> }
>> (I believe you are referring to this example code).
>>
>> I think that @Inject was used because the Resource is a @Singleton,
>> thus managed by the container.
>>
>> Please don't regret anything. We can change anything we want and
>> that's why we are asking for feedback.
>>
>> Regards,
>> Pavel
>>
>> On 10/02/2017 00:52, Sergey Beryozkin wrote:
>>> So supporting @Inject is a must now for JAX-RS 2.1 which a minor
>>> maintenance release ?
>>>
>>> What is it ? @Context for one thing, @Inject for another one, both
>>> parts being related to SSE ?
>>>
>>> Can that Sse be rather mapped to RuntimeDelegate ?
>>>
>>> I regret I raised that Broadcaster issue...
>>>
>>> Sergey
>>>
>>> On 09/02/17 21:22, Pavel Bucek wrote:
>>>>
>>>> Dear experts,
>>>>
>>>> thanks for all the feedback you've provided on presented Server
>>>> Sent Events proposal.
>>>>
>>>> Based on your feedback (and other inputs, most of them from Marek,
>>>> the original author of SSE proposal), we'd like to present another
>>>> iteration.
>>>>
>>>> *List of changes:*
>>>>
>>>> - SseEventInput is gone.
>>>> - We don't need to be able to receive events in blocking
>>>> fashion. If a user needs to do that, he still can - using a Deque
>>>> and onEvent consumer (and some synchronization).
>>>> - SseClientSubscriber is gone.
>>>> - replaced by EventSource#subscribe(Consumer<InboundSseEvent>)
>>>> and other overloads.
>>>> - SseEventOuput is now SseEventSink (the opposite to SseEventSource).
>>>> - SseContext is now Sse (its not a context).
>>>> - Introduced SseSubscription (which will extend Flow.Subsription
>>>> when we can use Java SE 9).
>>>> - SseEventSink (used to be SseEventOutput) is now injectable -
>>>> there is no other way how to create it:
>>>>
>>>> @GET @Path("events")
>>>> @Produces(MediaType.SERVER_SENT_EVENTS)
>>>> public void itemEvents(@Context SseEventSink serverSink) {
>>>> serverSink.onNext(sse.newEvent().data("welcome").build());
>>>> broadcaster.subscribe(serverSink);
>>>> }
>>>>
>>>> please note that the resource method now doesn't return injected
>>>> SseEventSink - it's more similar to the pattern used in async API
>>>> and users don't need to repeat "sseContext.newEventOutput();" and
>>>> "return eventOutput;".
>>>>
>>>> All these changes are done in a single commit:
>>>> https://github.com/jax-rs/api/commit/459ddb615861959e4899b48d0b88498100308bcd
>>>>
>>>> We also added couple of helper methods to create an outbound event:
>>>> https://github.com/jax-rs/api/commit/8a61f14b2797cfa22da1c0fdb1b5a321ca435c8b
>>>>
>>>> Please let us know what you think.
>>>>
>>>> Thanks and regards,
>>>> Pavel & Santiago
>>>
>>>
>>
>