Hi Markus - OK, thanks.
Still looks like a foreign body, this @Produces...
The question about formatting the event data fragments still remains,
If we are including MBW then surely not because we need a help with
writing String into output stream.
Oh, actually.
https://github.com/mpotociar/api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/sse/OutboundSseEvent.java#L108
So ended up doing some home work after all :-)
Sergey
On 21/10/15 19:05, Markus KARG wrote:
>
> Sergey,
>
> maybe there is a misunderstanding: The W3C SSE specification clearly
> says that the initiation of a SSE channel _is_ by declaring a content
> type of text/event-stream. Hence this is not a marker made up by
> JAX-RS, but it definitivel _is_ correct according to the W3C.
>
> -Markus
>
> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> *Sent:* Mittwoch, 21. Oktober 2015 13:26
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> *Subject:* Re: [jax-rs-spec users] SSE Draft
>
> Hi Marek
>
> Few comments/questions,
>
> Re the special MediaType vs the MediaType for individual event writes,
>
> How is a Media Type for an event data fragment is specified ?
> And can we assume that the same MediaType is used for all the event
> writes ?
>
> If it is a single Media Type then I'd object to the idea of a
> *special* MT, example, if every event write is a JSON payload, why do
>
> @POST
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public SseEvenOutput startDomain() {
> }
>
> This actually appears to be a bit off the JAX-RS style because we use
> MediaType.SERVER_SENT_EVENTS as a marker of the method which initiates
> SseEvenOutput but not the *format* of the response event data chunks,
> it overloads the concept of Produces IMHO.
>
> Should we just have
>
> @POST
> @Produces(MediaType.APPLICATION_JSON)
> public SseEvenOutput startDomain() {
> }
>
> Which is more in line with a StreamingOutput like pattern ?
>
> The runtime can mark startDomain() as needed given the response type
> is SseEvenOutput and if Response (or AsyncResponse ?) are allowed then
> we can do
>
> @POST
> @Produces(MediaType.APPLICATION_JSON)
> @SSE
> public Response startDomain() {
> }
>
>
> Thoughts ?
>
> Cheers, Sergey
>
>
>
>
>
>
>
>
>
> On 21/10/15 11:42, Marek Potociar wrote:
>
> 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
> <mailto: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
> <mailto: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
> <mailto: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?
>