Sergey, no offense taken. I do not want to strongly tie to full-blown CDI. I
only want to use that sole part of it. As it is nothing more that a simple
listener and a fire method, it would be even simpler to implement as the
original proposal, I assume! I also would like to have a meeting one day. If
you're in Germany, let me know. :-)
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Dienstag, 20. Oktober 2015 22:51
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: SSE Draft
Hi Markus
I do not propose to ignore it but not to *strongly* tie to it.
Perhaps, in this case, RI can offer a CDI to SSE event mapping mechanism
(if that is realistic) - may be that can address you even system
duplication concerns.
But as I said, the concern is CDI may not offer an event support for API
that is possibly can require a richer/more specific event support...
Either way - hope to see you at Apache Con one day and have some chat :-)
Sorry if I was too unreasonable in my response below.
Cheers, Sergey
On 20/10/15 21:43, Markus KARG wrote:
> 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
>>
>