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