Re 3) I need to object here. Ignoring Java EE is ridiculous looking at the
number of Java EE based JAX-RS deployments compared to Java SE based
deployments. Java EE is the de-facto main deployment environment, and deeply
integrating with CDI is not only a logical next step looking at the Java EE
8 target architecture (which is CDI based), but actually CDI integration is
also an item of the published JSR 370 charter. -1 for any non-CDI-compatible
event system and reinventing the wheel.
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Dienstag, 20. Oktober 2015 17:17
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: SSE Draft
Re 1) Yes, this is my understanding too that the response goes via a chain
of response filters/writers/MBWs
Re 3) I think the attempts to 'marry' various eventing systems meant for
different things will lead to a restricted and less useful API. We should
strive to make Web JAX-RS users happy as opposed to 'squeezing' JAX-RS into
J2EE
Sergey
________________________________________
From: Markus KARG <markus_at_headcrashing.eu>
Sent: 19 October 2015 22:19
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: RE: SSE Draft
(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.
-Markus
On 14/10/15 10:28, Sergey Beryozkin wrote:
>>
>> (3) SSE:
>>
>> https://github.com/mpotociar/api/tree/master/examples/src/main/java/j
>> axrs/examples/sse
>>
>>
>> Note that like in NIO, there are proposed extensions to both the
>> Client and Server APIs for SSE.
>>
>
> I think it is written in the spirit of JAX-RS - I'll have more
> comments in due time, but I'm positive after a quick glance
>
> Sergey