Sergey, I did not select the people that visited the presentations. I am
pretty sure many of them are not using Java EE. I realize that there are
different platforms, just as I am very well aware of the platforms defined
by the spec. But I cannot ignore Java EE just because of the non-Java EE
users or vendors. I don't understand what you like to claim with your
charge, as my JAX-RS presentations actually DO start with the Ed Burns quote
"JAX-RS is the most important part of Java EE". I do see the _full_ picture
very well, and I do love the lean solutions like TomEE+ and even Java SE.
But my vision is not to _ignore_ Java EE; it is to use CDI on Java SE, too!
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Dienstag, 20. Oktober 2015 22:31
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: SSE Draft
Why don't you present your JAX-RS presentation at least once to people
outside of
Java EE world - I'm not sure you realize the other world exists but it
is, and ask them first which Java EE spec
they know about, and the high chance they will tell you it is JAX-RS.
And then ask yourself why. Because it's been open which made it more
popular than any other EE spec only yourself and few other people know
about
Sergey
On 20/10/15 21:25, Markus KARG wrote:
> 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
>
>