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

From: Markus KARG <>
Date: Tue, 20 Oct 2015 22:37:55 +0200

If we cannot, why did the JCP accept the JSR 370 charter, which clearly requests CDI integration?

-----Original Message-----
From: Sergey Beryozkin []
Sent: Dienstag, 20. Oktober 2015 22:23
Subject: Re: SSE Draft

Can a 2.1 (non major version) introduce a strong CDI dep ? MVC is a diff


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?