Well, according to the JCP bylaws, it is the expert group to define the outcome of the JSR. So it is up to us to interpret the charter as we like. ;-)
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Dienstag, 20. Oktober 2015 22:43
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: SSE Draft
Hi Markus
I suspect it is about better support for Inject, etc, but not sure
Cheers, Sergey
On 20/10/15 21:37, Markus KARG wrote:
> If we cannot, why did the JCP accept the JSR 370 charter, which clearly requests CDI integration?
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Dienstag, 20. Oktober 2015 22:23
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: Re: SSE Draft
>
> Can a 2.1 (non major version) introduce a strong CDI dep ? MVC is a diff
> story.
>
> Sergey
>
> On 20/10/15 16:26, Bill Burke wrote:
>>
>> On 10/19/2015 5:19 PM, Markus KARG wrote:
>>> (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.
>>>
>> What would SSE over CDI look like?
>>
>>
>