users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 20 Oct 2015 21:23:17 +0100

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?
>
>