Markus,
We should probably come up with a different example to better reflect how the API works. There is nothing in the API that requires the use of @Singleton for things to work. It is possible to write SSE samples using the default request scope and without using statics (but with the SseContext injected as shown in the example).
— Santiago
> On Oct 26, 2015, at 2:31 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
>
> Santiago and Marek,
>
> I discovered one more issue with the SSE proposal and like to ask the following question:
>
> The SSE example you posted uses the @Singleton annotation from the javax.inject package. Typically this instructs a Java EE server to create exactly one instance of a JAX-RS resource, hence is a guarantee that both, the SSE event source and the SSE event sink are defintively the same instance due to the singleton JAX-RS resource. This constraint apparently is needed to allow the SseEventOutput to correctly route the events from the SSE event source (the one being triggered by a posting client) to the SSE event sink (the one pushing SSE clients).
>
> As the JAX-RS specification does not say that support for @Singleton is mandatory on non-Java EE environments, the question is: How will this routing from SSE source to SSE sink work on Java SE? Will it be necessary for the application programmer to explicitly use a shared, static instance, or do you plan to provide some kind of service registry where shared SseEventOutput instances have to be looked up (which would also work on Java EE as a common programming model)? Related is the question whether different kinds of JAX-RS resources will be able to share an instance of SseEventOutput, so for example Resource A will push and event to SSE clients whenever a method of Resource B is invoked?
>
> Thanks
> -Markus