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 <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?
>>>
>>
>>
>