I did not say that JAX-RS must only run in CDI environments. What I say is that if we want tighter CDI integration, then we certainly should use CDI for that kind of problem. We could simply use the same annotations, so it is compatible when CDI is there, otherwise it emulates _that_part_ of CDI. And again, I just wrote few minutes ago, that I also want those other environment and am very fond of Java SE. But I do not want another annotation / class for something that exists in CDI already.
-----Original Message-----
From: Santiago Pericasgeertsen [mailto:santiago.pericasgeertsen_at_oracle.com]
Sent: Dienstag, 20. Oktober 2015 22:43
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] Re: SSE Draft
> On Oct 20, 2015, at 4:37 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
>
> If we cannot, why did the JCP accept the JSR 370 charter, which clearly requests CDI integration?
You keep mudding things up Markus, “better integration with CDI” does not imply that JAX-RS should only run in environments in which CDI is available. In fact, the spec is very clear about those environments.
— Santiago
>
> -----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?
>>
>>
>
>