Markus,
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 <markus_at_headcrashing.eu> 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 [mailto:sberyozkin_at_talend.com]
> Sent: Dienstag, 20. Oktober 2015 17:17
> To: jsr370-experts_at_jax-rs-spec.java.net
> 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 <markus_at_headcrashing.eu>
> Sent: 19 October 2015 22:19
> To: jsr370-experts_at_jax-rs-spec.java.net
> 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:
>>>
>>> https://github.com/mpotociar/api/tree/master/examples/src/main/java/j
>>> 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
>
>
>