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

From: Sergey Beryozkin <>
Date: Tue, 20 Oct 2015 21:30:33 +0100

Why don't you present your JAX-RS presentation at least once to people
outside of
Java EE world - I'm not sure you realize the other world exists but it
is, and ask them first which Java EE spec
they know about, and the high chance they will tell you it is JAX-RS.
And then ask yourself why. Because it's been open which made it more
popular than any other EE spec only yourself and few other people know

On 20/10/15 21:25, 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