Hi Sergey,
that is still true, but with these new methods on Sse "context", we'd
remove the need for having JAX-RS Resources as singleton, since the
"store" on the Sse would be application-scoped.
(let me add a code example to be extra sure we are on the same page)
current state:
(the synchronization could be done in a better way, please take it only
as an example)
@Path("server-sent-events")
public class ServerSentEventsResource {
private final Ssesse;
private static SseBroadcasterbroadcaster;// ... per-class broadcaster storage public ServerSentEventsResource(@Context Sse sse) {
this.sse = sse;
}
private static synchronized SseBroadcaster getBroadcaster(Sse sse) {
if (broadcaster ==null) {
broadcaster = sse.newBroadcaster();
}
return broadcaster;
}
@POST public void sendMessage(final String message)throws IOException {
getBroadcaster(sse).broadcast(sse.newEvent(message));
}
// ... }
future?:
@Path("server-sent-events")
public class ServerSentEventsResource {
private final Ssesse;
public ServerSentEventsResource(@Context Sse sse) {
this.sse = sse;
}
@POST public void sendMessage(final String message)throws IOException {
sse.getBroadcaster(this.getClass()).broadcast(sse.newEvent(message));
}
// ... }
Thanks,
Pavel
On 29/03/2017 12:34, Sergey Beryozkin wrote:
> 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
>
>