You misunderstood. Please check my explanation f using CDI just sent to Bill. And yes, ALL events must go through CDI, otherwise a whole lot of real-world-scenarios will never be able to attach to SSE. For example, I know many people using old-school technology like JCA to receive events, and they want to trigger SSE push in turn. Tell me how to do that without CDI, and I am on your side then. I just cannot accept a SSE solution that is part of Java EE, but that is not compatible with Java EE, simply spoken.
-----Original Message-----
From: Santiago Pericasgeertsen [mailto:santiago.pericasgeertsen_at_oracle.com]
Sent: Dienstag, 20. Oktober 2015 22:39
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: SSE Draft
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
>
>
>