[jax-rs-spec users] Re: Minor SSE API changes

From: Sergey Beryozkin <>
Date: Wed, 29 Mar 2017 11:34:51 +0100

HI Pavel

That works for us. Recall that you said that 'Sse' object can be
injected with a JAX-RS @Context and
assuming the service resource is called DemoResource this works for
either per-request or singleton,
public class DemoResource {
    public DemoResource(@Context Sse sse) {}

For ex, if DemoService is per-request then the following works right now:

public DemoResource(@Context Application app) {}

Both 'contexts' are very much similar in that both are effectively the
non-request specific factories

Thanks, Sergey

On 29/03/17 11:10, Pavel Bucek wrote:
> Dear experts,
> we did a couple of changes in SSE API:
> - removed SseEventSource.Builder#named(...)
> the intention was to name threads used by the event source, but in the
> light of future change, which should introduce "common" per-client
> thread pool(s) for async operation, this won't be feasible to have
> there (since it would require creating another threadpool per
> SseEventSource instance)
> - SseEventSource now implements Flow.Source<InboundSseEvent>
> seems like we'd need to have some form of Publisher and Subscriber,
> currently named as Source and Sink in the API. The main reason would
> be integration with other frameworks - without it, it would be harder
> to do without a good reason.
> Also, during the implementation and rewriting "old" Jersey examples,
> one difficulty was discovered. It used to be possible to create a
> broadcaster statically, which simulates "per resource class" scope.
> The problem is that currently the only way how to create a new
> SseBroadcaster is injecting Sse object. But that is not available
> during static initialization and since JAX-RS resources are by default
> request-scoped, storing the SseBroadcaster instances might be a
> challenge for some users.
> Does anyone see the same issue as we do?
> Would someone object if we add methods like
> Sse#getBroadcaster(String)
> Sse#getBroadcaster(Class<?>)
> which would serve as a storage for broadcasters? (semantically it
> could be "get-or-create", passed String or Class would serve as a key).
> Thanks and regards,
> Pavel