Marek,
thank you for making your vision more clear. I have more questions:
* If not by means of CDI, how shall an application programmer then implement the following, typical Java EE scenario: "JCA adapter recognizes data change in ERP system, wants to publish the update by means of SSE."?
* Why skipping Filters and Interceptors? If you really treat SSE simply like a content type, then each data message is nothing else but an entity just like in a "normal" response. So wouldn't it make sense to pass that data message through the same filter and interceptor chains like just any "normal" response?
* Regarding "it is only natural that the JAX-RS resources return the new instance of SSE stream from a resource method." you are certainly right from a technical view, but as it is always the same code to write, maybe this can be automated by the JAX-RS container? I mean, as the returned content type is event-stream, you could even have "void" return type in the method signature and the container still would know what is intended.
* Regarding no abstracting away SSE complexity I now understand you vision (thanks for the explanations; the Java code was simply not enough to make it clear), but looking from the angle you describe, I have to object in a different manner then: Do we really need _all_ that eight classes? I'm still not convinced, possibly because there is no bug picture outlined _why_ all of these classes exist.
All in all I think the SSE API is going in the right direction, it is just hard to share your vision right from the start, when information is not provided in one single, bug picture.
-Markus
From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
Sent: Mittwoch, 21. Oktober 2015 12:43
To: Markus Karg
Cc: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] SSE Draft
At the same time, it is the spec lead job to steer the EG and the JSR outcome. And since it was me and Santiago who submitted the JSR charter, EG does not need to find interpretations, EG can simply ask the spec leads to provide the explanation. đ
In case of CDI, our intention was to improve the alignment of @Inject and scope support. FWIW, weâre still hoping that CDI 2.0 will become more modularized so that we do not have to formally deal with the whole spec (that becomes more and more bloated by features less and less relevant to âcontext and dependency injectionâ problem), only with itâs core pieces. So once, again, our CDI alignment is about aligning the JAX-RS injection support with CDI. It is NOT about integration with CDI eventing (for SSE support or whatever other purpose).
Hope the explanation above is clear enough and does not require further interpretation in EG.
As for the SSE support, we want to provide a facility that fits well into JAX-RS programming model. And since SSE is really just a (special) media type, the proposed API is building on top of the existing support for entity providers in JAX-RS. So to touch on the questions you raised in more detail:
- Yes, we plan to leverage message body readers and writers for each single SSE event. We do not plan to engage Filters and Interceptors with each event, those should only be engaged when the request or response is initiated.
- Injectable SseEventOutput is certainly an option to consider. At the same time, we do need to find a way how to provide access to event builder and broadcaster, so rather than injecting three separate things, it so far seems to me simpler to just inject the context and use it to get access to all of the important components. In any case, we can simply look into this further to see what can be done to make the API simpler.
- To your comment "I do not see why creating the SseOutput from an SseContext should be the responsibility of the application programmer.â, my response is that SSE stream is a representation of a resource in the JAX-RS philosophy. So it is only natural that the JAX-RS resources return the new instance of SSE stream from a resource method. Thatâs the common JAX-RS programming model.
- To respond to your item #3, other than my CDI related comments earlier in this email, SSE is a standardized spec with well defined standard APIs. It IMO begs for a dedicated API. Otherwise it would not make any sense to provide a special support for it. It is only good that we can come up with a really small API (8 classes) that fits well the JAX-RS programming model and is tailored to support this technology. SSE is a specific technology that covers important, but again specific use cases. Coming up with some clever abstractions is not going to provide any real user value, Iâm afraid.
Cheers,
Marek
On 20 Oct 2015, at 22:53, Markus KARG <markus_at_headcrashing.eu> wrote:
Well, according to the JCP bylaws, it is the expert group to define the outcome of the JSR. So it is up to us to interpret the charter as we like. ;-)
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Dienstag, 20. Oktober 2015 22:43
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: SSE Draft
Hi Markus
I suspect it is about better support for Inject, etc, but not sure
Cheers, Sergey
On 20/10/15 21:37, Markus KARG wrote:
If we cannot, why did the JCP accept the JSR 370 charter, which clearly requests CDI integration?
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Dienstag, 20. Oktober 2015 22:23
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: SSE Draft
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?