Hi
I have to admit I'm still uncomfortable about a specialized
Produces(text/event-stream) in this case. I could not figure why until
yesterday... Basically this is what the SSE spec requires to accompany
the data going to the SSE channel - but it is orthogonal to the act of
converting the data into event specific formats such as JSON or plain text.
When myself and possibly other users see Produces they think this is the
format of the response data.
Having an SSE-required MT in a method @Produces does not fit well into a
JAX-RS state of 'mind'.
Letting people set MT for individual events actually loosens the API -
i.e, the API makes it very easy to do what is obviously not meant to be,
mixing different formats in a single channel, 1st event is JSON, next is
XML. Of course we can say the users needs to know what to do, but it is
different from having an API which does not explicitly allows such
nonsense operations...In 2.0 one can also do it, say mess up with
writing into StreamingOutput - but the user needs to try hard :-)
I'd like to return to discussing this idea:
@POST
@Produces(MediaType.APPLICATION_JSON)
public SseEvenOutput startDomain() {
}
or
@POST
@Produces(MediaType.APPLICATION_JSON)
@SSE
public Response startDomain() {
}
In either case, setting text/event-stream is the responsibility of the
runtime, something that will be documented in the spec/API, it is
implicit, while
@Produces(MediaType.APPLICATION_JSON) represents the format of the every
event fragment for a given SSE output channel...
Sergey
On 22/10/15 16:11, Sergey Beryozkin wrote:
> Hi Santiago
> On 22/10/15 15:29, Santiago Pericasgeertsen wrote:
>> Sergey,
>>
>> This is how I reason about media types associated with events.
>> First, sometimes the data associated with an event is structured,
>> most notably these days it’s JSON. JAX-RS already has a facility for
>> mapping Java objects to representations (MBR/MBW) whose selection is
>> based on MTs.
>>
>> This mechanism is there for entities, but it is only natural to see
>> if it can be extended for SSE event data. To do so, you need to
>> specify an MT for the event’s data. If we don’t allow re-usability of
>> this mechanism, we’d either only support string messages or build a
>> completely different mechanism, which seems like an overkill.
>>
> Sure, +1, indeed reusing MBR/MBW for this is perfect
>
>> I’m still unsure about interceptors: to me interceptors and
>> MBR/MBW’s are inseparable, but at the same time it’s not clear what
>> advantages they bring in this case.
>>
> I've no strong opinion right now about it. I can imagine some
> confusion about the response interceptors/filters meant for processing
> 'main' HTTP channel responses being also used for filtering sse
> events, though I can also imagine may me some events being blocked by
> filters if needed, not really sure right now :-)
>
> Sergey
>
>> — Santiago
>>
>>> On Oct 21, 2015, at 4:46 PM, Sergey Beryozkin <sberyozkin_at_talend.com
>>> <mailto:sberyozkin_at_talend.com>> wrote:
>>>
>>> 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> 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?
>>>>
>>>
>>>
>>
>