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

From: Bill Burke <>
Date: Wed, 21 Oct 2015 09:36:25 -0400

On 10/20/2015 4:36 PM, Markus KARG wrote:
> 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).

CDI is component to component events intra-VM. SSE is pushing/receiving
events from the network. JAX-RS is a protocol to Java mapper. The
whole point of JAX-Rs is to declaratively map request and responses to
HTTP. I actually don't kno how CDI could fit as you want to control
*exactly* how data is mapped to the outgoing SSE event, or unmarshalled
from an incoming one.

This is why I wanted to know how SSE over CDI would look and how you
would define this mapping between CDI and HTTP/SSE.

Bill Burke
JBoss, a division of Red Hat