[jax-rs-spec users] Re: SSE in non-JavaEE environments

From: Markus KARG <>
Date: Mon, 4 Jan 2016 19:57:39 +0100



From: Santiago Pericasgeertsen []
Sent: Montag, 4. Januar 2016 19:29
Subject: Re: [jax-rs-spec users] SSE in non-JavaEE environments



On Nov 28, 2015, at 9:21 AM, Markus KARG <> wrote:




thank you for posting the link. Unfortunately this still does not answer my questions…:


* In a JAX-RS environment that does not provide @Singleton, how to guarantee (without voiding the WORA principle) that all instances of a SSE-enabled resource class share the same SSE broadcasting space, i. e. instance A receives an event, instance B must broadcast it to any it its open SSE clients. How does JAX-RS guarantee this functionality even in a cloud environment, where instance A possibly lives in JVM 1 while instance B lives in JVM 2?




So that means that the SSE support inherently won't work with vertical scaling (hence, singletons, either by getSingletons or by @Singleton, are a MUST)? What happens if SSE but not using singletons?


* How can one JAX-RS resource use multiple event streams, so clients will only receive events for "their" stream?


 One way would be to use different event types, but this is really a layer above SSE.

So that means that SSE enabled resources MUST have exactly one single SSE stream?


* When I receive a JMS event in a message driven bean, how can I forward the event to SSE clients?


 Are you concerned about getting a hold of a broadcaster?


Unfortunately I don't understand the question (maybe my English is too bad?).


— Santiago






From: Marek Potociar []
Sent: Freitag, 27. November 2015 17:06
Subject: Re: [jax-rs-spec users] SSE in non-JavaEE environments


Just for your reference, here’s the link to the pull request:





On 27 Nov 2015, at 17:05, Marek Potociar < <>> wrote:


Not sure I understand I did post the full code. What else do you need?




On 24 Nov 2015, at 17:55, Markus KARG < <>> wrote:


I think it would be best if Santiago posts the proposed full code example. I believe that your proposal is well-done, but I simply need to see some source code answering my original question. :-)


From: Marek Potociar [ <>]
Sent: Montag, 23. November 2015 16:51
To: <>
Subject: Re: [jax-rs-spec users] SSE in non-JavaEE environments


Hi Markus,


This is the assumption in our current design:


SSE Output = single SSE client connection


Does that make the concept clearer?





On 27 Oct 2015, at 20:14, Markus KARG < <>> wrote:


So this means that there is only one SseContext for all injections? How to separate the different "event sinks" then? The code example only shows "sslContext.newOutput()"… so is there only one "event sink" for all resources, or is the "event sink" private to the resource class… or is there a "newOutput(String eventSinkName)"?


From: Santiago Pericasgeertsen [ <>]
Sent: Dienstag, 27. Oktober 2015 19:36
To: <>
Subject: Re: [jax-rs-spec users] SSE in non-JavaEE environments




 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 < <>> 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?