users@jax-rs-spec.java.net

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

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 20 Oct 2015 11:26:01 -0400

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?


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com