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

From: Santiago Pericasgeertsen <>
Date: Tue, 20 Oct 2015 16:38:49 -0400


 CDI events are great, but not everything with the word “event” in it should be routed through CDI. SSE is an HTML5 standard, a wire protocol and JS API, and completely unrelated to CDI events. The connection with JAX-RS is via HTTP and not CDI events —which is about beans firing and observing events.

 There are lots of JAX-RS users that run in environments without CDI. I don’t even want to go there …

— Santiago
> On Oct 20, 2015, at 4:25 PM, Markus KARG <> wrote:
> Re 3) I need to object here. Ignoring Java EE is ridiculous looking at the
> number of Java EE based JAX-RS deployments compared to Java SE based
> deployments. Java EE is the de-facto main deployment environment, and deeply
> integrating with CDI is not only a logical next step looking at the Java EE
> 8 target architecture (which is CDI based), but actually CDI integration is
> also an item of the published JSR 370 charter. -1 for any non-CDI-compatible
> event system and reinventing the wheel.
> -----Original Message-----
> From: Sergey Beryozkin []
> Sent: Dienstag, 20. Oktober 2015 17:17
> To:
> Subject: Re: SSE Draft
> Re 1) Yes, this is my understanding too that the response goes via a chain
> of response filters/writers/MBWs
> Re 3) I think the attempts to 'marry' various eventing systems meant for
> different things will lead to a restricted and less useful API. We should
> strive to make Web JAX-RS users happy as opposed to 'squeezing' JAX-RS into
> J2EE
> Sergey
> ________________________________________
> From: Markus KARG <>
> Sent: 19 October 2015 22:19
> To:
> Subject: RE: SSE Draft
> (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.
> -Markus
> On 14/10/15 10:28, Sergey Beryozkin wrote:
>>> (3) SSE:
>>> axrs/examples/sse
>>> Note that like in NIO, there are proposed extensions to both the
>>> Client and Server APIs for SSE.
>> I think it is written in the spirit of JAX-RS - I'll have more
>> comments in due time, but I'm positive after a quick glance
>> Sergey