[jax-rs-spec users] Re: SSE Draft

From: Markus KARG <>
Date: Tue, 20 Oct 2015 22:36:50 +0200

In fact I did never propose "SSE over CDI".

What I said was simply that I do not want to have another _JAX-RS-specific_ API simply for synchronizing a waiting party and a sending party. CDI events are THE common solution for this kind of design problem. There is no good reason to reinvent the wheel just for the SSE case.

Using CDI you can declare that there is a listener method to be fired whenever an event of a particular type is fired. Both, the listener and the firing party of the CDI event, can be any Java EE component -- including, but not limited to JAX-RS resources. So it makes to sense to provide another solution, which only works within JAX-RS, and particularly only with SSE, but not with other pushing technologies possibly added later or by third parties.

The correct API design would be that the JAX-RS resource sends a SSE data message in reaction to a CDI event, and it can (just like all other Java EE components) fire a CDI event from within a JAX-RS resource (or any other JAX-RS component).


-----Original Message-----
From: Bill Burke []
Sent: Dienstag, 20. Oktober 2015 17:26
Subject: Re: SSE Draft

On 10/19/2015 5:19 PM, Markus KARG wrote:
> (1) Maybe I missed the code line, but will it be possible to send an entity so MBWs, Filters and Interceptors are getting involved? In the end, we do not write an SSE server, but actually do add SSE to JAX-RS.
> Like: sseContext.newEvent().name("custom-message").data(myEntity); => use MBW to stream entity, applying all filters and interceptors that are registered for the resource class that owns this SSE channel.
> (2) I am not convinced that the complexity is needed. Why is there a SseEventOutput and an SseContext? Can't we simply inject an SseOutput in the resource automatically? I do not see why creating the SseOutput from an SseContext should be the responsibility of the application programmer.
> (3) I am not convinced that the technology of SSE should also bring with it its own eventing subsystem. Wouldn't it make more sense to rely on CDI events? Using CDI events we could allow events origin from other Java EE components (like JCA, MDB or timed EJBs) to be forwarded in a protocol-transparent way into the JAX-RS container, which then is the only one that has to know that SSE is used to transport the event to the http client. As JAX-RS is an integral part of Java EE, and as SSE is a web-only technology, I don't like the idea that either non-web-components are polluted by SSE, or non-web-events couldn't be forwarded to SSE clients.

What would SSE over CDI look like?

Bill Burke
JBoss, a division of Red Hat