Hi Andriy,
This is a good observation - thank you for spotting this. I’ll give it some thought and come up with a fix proposal.
Cheers,
Marek
> On 14 Aug 2016, at 04:36, Andriy Redko <drreta_at_gmail.com> wrote:
>
> Hey JAX-RS leads,
>
> As some of you may already know, the Apache CXF project is one of the early adopters of
> the JAX-RS 2.1 specification. In particular, we are currently actively working on implementing
> SSE support, based on drafted JAX-RS 2.1 API. Along the way we stumbled upon some design
> decisions which may require a bit of clarification or (hopefuly) a second thought. The use case
> in question is related to SseBroadcaster. Essentially, the idea sounds pretty simple: events
> into multiple SSE streams could be easily broadcasted. F.e. here is a pseudo-code for typical
> scenario:
>
> SseBroadcaster broadcaster = new SseBroadcasterImlp();
>
> broadcaster.register(stream1);
> broadcaster.register(stream2);
> ...
>
> broadcaster.broadcast(event1);
> broadcaster.broadcast(event2);
>
> In nutshell, current Jersey's SSE implementation does exactly that. However, in JAX-RS 2.1 API
> draft SseBroadcaster could be created only from SseContext, f.e.:
>
> Response stream(@Context SseContext context) {
> SseBroadcaster broadcaster = context.newBroadcaster();
> broadcaster.register(context.newOutput());
> ...
> }
>
> It kind of works but totally defeats the idea of broadcaster as being independent from SseContext or/and
> streams it serves. Currently, every time new instance of the SseBroadcaster will be created, with no
> straightforward way to share it across multiple SSE streams. How it could work though may look like that
> (the implementation details could vary, just trying to present the idea):
>
> private SseBroadcaster broadcaster = SseBroadcaster.newBroadcaster();
>
> Response stream1(@Context SseContext context) {
> broadcaster.register(context.newOutput());
> ...
> }
>
> Response stream2(@Context SseContext context) {
> broadcaster.register(context.newOutput());
> ...
> }
>
> In this case, the SseBroadcaster is truly context-independent, and serves it purpose very well. We were trying to
> come up with some realistic scenarios for SseBroadcaster utilizing the current specification draft but did not really
> succeeded. Surely, there are a few way to make it work but they do not look good. Does it make sense? Whould you
> mind guys to give some clarifications/guidance on that?
>
> Thank you a lot!
>
> Best Regards,
> Andriy Redko