On 10/11/15 15:19, Santiago Pericasgeertsen wrote:
>
>> On Nov 10, 2015, at 9:58 AM, Sergey Beryozkin <sberyozkin_at_talend.com
>> <mailto:sberyozkin_at_talend.com>> wrote:
>>
>> On 10/11/15 14:50, Santiago Pericasgeertsen wrote:
>>>
>>>> On Nov 8, 2015, at 12:52 PM, Sergey Beryozkin
>>>> <sberyozkin_at_talend.com <mailto:sberyozkin_at_talend.com>> wrote:
>>>>
>>>> Hi Santiago
>>>>
>>>> I guess the source of my own 'confusion' is this one:
>>>>
>>>> - text/sse-stream CT has no relationship to the actual content
>>>> being returned
>>>> while in a normal HTTP a CT has a direct relationship (so much
>>>> for SSE being HTTP friendly)
>>>
>>> No, this is not true. The stream that you’re returning looks like this:
>>>
>>> event: foo
>>> data: { “a” : “b”}
>>>
>>> event: bar
>>> data: { “c” : “d”}
>>> …
>> Well, obviously I referred to the 'data' piece, so indeed
>> text/sse-stream has no relation to
>> { “c” : “d”}
>
> It does in the sense that you’re sending “text”, which in this
> example happens to be JSON. In fact, every data event can have a
> different “type” of text in same stream: an event’s data could be
> application/json and another event’s data could be text/plain. This is
> why a default makes more sense than an annotation that we normally use
> to refer to the entire stream not a single event.
>
So given this line about 'text' being also 'json' why with
@Produces(text/event-stream) users still has to set application/json on
the builder when writing event beans that are meant to be written as JSON ?
My answer: because @Produces has been overloaded, i.e, SseOuputChannel
is obviously taking care of formatting the SSE payload.
@Produces(text/event-stream) does not help a bit in selecting
SseOuputChannel - the method returns it for the runtime to use.
I did not propose to remove 'text/event-stream'. I'm saying that lets
keep @Produces for what it always does in JAX-RS - for affecting the
selection of MBW, while also letting SSE users know that the overall
production is an SSE output channel (@SseProduces, or implicitly -
SseOutputChannel response type)
Sergey
> — Santiago
>
>>
>>>
>>> The overall structure is SSE and not JSON.
>>>> - @Produces in JAX-RS has always had an effect on selecting the
>>>> response CT, *but also* on MBR - while
>>>> a @Produces("text/sss-stream") does not help with selecting MBR
>>>> which implies that in this case we partially overload it.
>>>
>>> Look above, someone needs to insert the tags “event:”, “data:”, the
>>> right spacing, etc.
>>>
>> Well, so given what I've just clarified, where is the conflict, or
>> rather a worse version of supporting SSE compared to the current
>> version, in what I did propose ?
>>
>> Sergey
>>
>>> — Santiago
>>>
>>>> @POST
>>>> @SseProduces
>>>> @Produces(MediaType.APPLICATION_JSON)
>>>> public SseEvenOutput startDomain() {
>>>> }
>>>>
>>>> would be neater IMHO - @SseProduces is a reference to a technical
>>>> aspect of SSE, i.e. its req to have text/event-stream.
>>>> The meaning of @Produces(MediaType.APPLICATION_JSON) (only if it is
>>>> set - the builder is still available for event specific MT)
>>>> is the same as it is known to JAX-RS developers now - perhaps
>>>> something like APPLICATION_JSON
>>>> can be used to set that internal CT property (in the actual given
>>>> SSE payload) Markus referred to earlier - in which case it would be
>>>> completely consistent...
>>>>
>>>> Sergey
>>>>
>>>>
>>>> On 04/11/15 00:14, Santiago Pericasgeertsen wrote:
>>>>> Sergey,
>>>>>
>>>>> Hmm, I see what you mean, but I think that violates the spec. A
>>>>> method-level @Produces is supposed to override a class-level one,
>>>>> ultimately resulting in the value of Content-Type in the response.
>>>>>
>>>>> I think what you proposed will introduce a lot of confusion.
>>>>> Alternatively, we could provide a default MT programmatically for
>>>>> all events to be created instead, if that addresses the issue that
>>>>> you have in mind.
>>>>>
>>>>> — Santiago
>>>>>
>>>>>> On Nov 3, 2015, at 1:28 PM, Sergey Beryozkin
>>>>>> <sberyozkin_at_talend.com <mailto:sberyozkin_at_talend.com>> wrote:
>>>>>>
>>>>>> https://github.com/mpotociar/api/blob/46d81cf3c5826f62e5824d5330fa4d59ffa0d98f/examples/src/main/java/jaxrs/examples/sse/ServerSentEventsResource.java#L103
>>>>>> (1)
>>>>>>
>>>>>> Replace @Produces(text/event-stream) with
>>>>>> Produces(application/json) and add @SSE and that works neatly,
>>>>>> otherwise if we keep
>>>>>> @Produces(text/event-stream) there and have
>>>>>> Produces(application/json) at this level
>>>>>>
>>>>>> https://github.com/mpotociar/api/blob/46d81cf3c5826f62e5824d5330fa4d59ffa0d98f/examples/src/main/java/jaxrs/examples/sse/ServerSentEventsResource.java#L62
>>>>>> (2)
>>>>>>
>>>>>> then when I do
>>>>>>
>>>>>> https://github.com/mpotociar/api/blob/46d81cf3c5826f62e5824d5330fa4d59ffa0d98f/examples/src/main/java/jaxrs/examples/sse/ServerSentEventsResource.java#L112
>>>>>> (3)
>>>>>>
>>>>>> (but use MyBean instead to be serialized as JSON) the class level
>>>>>> Produces(application-json) (ref (2) above) it will be ignored and
>>>>>> the only way to set application/json is to use the builder.
>>>>>>
>>>>>> Sergey
>>>>>>
>>>>>> On 03/11/15 16:55, Santiago Pericasgeertsen wrote:
>>>>>>>
>>>>>>>> On Nov 3, 2015, at 4:10 AM, Sergey Beryozkin
>>>>>>>> <sberyozkin_at_talend.com> wrote:
>>>>>>>>
>>>>>>>> Hi Santiago
>>>>>>>>
>>>>>>>> So I'm wondering if inserting a special MT would interfere with
>>>>>>>> the regular policy of figuring out what MT should be allocated
>>>>>>>> to a given data piece.
>>>>>>>> Example if I do not use SSE, I can put Produces on Class or on
>>>>>>>> Method or in Response. If we keep depending on a special MT to
>>>>>>>> make a method initiating an SSE output then the only mechanism
>>>>>>>> to set an event data MT is to use a builder, neither Class or
>>>>>>>> Method Produces can be used which would be unfortunate IMHO.
>>>>>>>
>>>>>>> I’m not sure I follow. The MT of the method/class/response is
>>>>>>> always text/event-stream, so indeed any other MT will be
>>>>>>> supplied while constructing each SSE event. Is that what you
>>>>>>> meant? If not, please provide some code :)
>>>>>>>
>>>>>>> — Santiago
>>>>>>>
>>>>>>>>
>>>>>>>> I'm not proposing to block text/event-stream but rather treat
>>>>>>>> it as a technical aspect of implementing SSE, i.e, it is an SSE
>>>>>>>> protocol specific 'demarcation' MT which does not have any
>>>>>>>> relevance to the format of the actual data (referring here to
>>>>>>>> the MT/format used to select JAXRS providers) pushed inside
>>>>>>>> this text/event-stream 'envelope'. Example, having both @SSE
>>>>>>>> for the purpose of marking the method and @Produces for the
>>>>>>>> purpose of specifying the *default* MT for the event data
>>>>>>>> fragments (while letting users override if with a builder if
>>>>>>>> needed) can work well.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sergey
>>>>>>>>
>>>>>>>> On 29/10/15 13:17, Santiago Pericasgeertsen wrote:
>>>>>>>>> Sergey,
>>>>>>>>>
>>>>>>>>> Inlined.
>>>>>>>>>
>>>>>>>>>> My understanding the format of the message is expected to be
>>>>>>>>>> known to the client (example, it is JSON all the time in a
>>>>>>>>>> known representation, etc),
>>>>>>>>>
>>>>>>>>> Yes, there is nothing in the SSE protocol about an event's
>>>>>>>>> MT. There is a single MT returned in the response, and that is
>>>>>>>>> text/event-stream. The reason for the MT proposal is simply so
>>>>>>>>> that JAX-RS can find the correct MBW.
>>>>>>>>>
>>>>>>>>>> I was more curious about the default MT that would be used
>>>>>>>>>> for selecting MBW for serializing a custom event object…
>>>>>>>>>
>>>>>>>>> In my view, this ought to be consistent with the way we
>>>>>>>>> handle the return of an entity in a resource method without an
>>>>>>>>> @Produces. In other words, it should be consistent with the
>>>>>>>>> algorithm in Section 3.8.
>>>>>>>>>
>>>>>>>>> — Santiago
>>>>>>>>>
>>>>>>>>>> If a builder media type property is not set then at least for
>>>>>>>>>> String toString() will produce a meaningful message, but a
>>>>>>>>>> Object.toString() should not be allowed to escape if a user
>>>>>>>>>> forgets to set a MT builder property
>>>>>>>>>>
>>>>>>>>>> Sergey
>>>>>>>>>> On 28/10/15 18:55, Markus KARG wrote:
>>>>>>>>>>> Quoted from W3C: <The default event type is "message">.
>>>>>>>>>>> Actually there is problem with MIME and SSE: W3C does not
>>>>>>>>>>> define how to transfer the Content-Type. They do specify
>>>>>>>>>>> that one can add any name to a field (like "content-type")
>>>>>>>>>>> but that name is not mandatory. Without it, our only chance
>>>>>>>>>>> is assuming "String", actually -- even if this means
>>>>>>>>>>> "toString()".
>>>>>>>>>>> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
>>>>>>>>>>> *Sent:*Mittwoch, 28. Oktober 2015 19:18
>>>>>>>>>>> *To:*jsr370-experts_at_jax-rs-spec.java.net
>>>>>>>>>>> *Subject:*Re: [jax-rs-spec users] SSE Draft
>>>>>>>>>>> Either by the return type or otherwise by something like
>>>>>>>>>>> @SSE, please see the prototype below
>>>>>>>>>>>
>>>>>>>>>>> By the way, this is probably orthogonal, but what is the
>>>>>>>>>>> default MT (for the purpose of selecting MBW) if the event
>>>>>>>>>>> object is not String but say MyEvent.
>>>>>>>>>>> Is toString() a default ? That would work for String but
>>>>>>>>>>> would look not good for custom objects
>>>>>>>>>>>
>>>>>>>>>>> Sergey
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 28/10/15 17:59, Markus KARG wrote:
>>>>>>>>>>>
>>>>>>>>>>> Understood. So how to detect SSE then if not by MT? By
>>>>>>>>>>> return type?
>>>>>>>>>>> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
>>>>>>>>>>> *Sent:*Mittwoch, 28. Oktober 2015 00:26
>>>>>>>>>>> *To:*jsr370-experts_at_jax-rs-spec.java.net
>>>>>>>>>>> *Subject:*Re: [jax-rs-spec users] SSE Draft
>>>>>>>>>>> Or per-event MT approach can still work where, if set,
>>>>>>>>>>> it overrides a method specific Produces, exactly as it
>>>>>>>>>>> works with a regular JAX-RS response.
>>>>>>>>>>> So I guess the only thing I suggest is to make setting
>>>>>>>>>>> text/event-stream implicit and keep Produces for
>>>>>>>>>>> specifying the event format if preferred...
>>>>>>>>>>>
>>>>>>>>>>> Sergey
>>>>>>>>>>> On 27/10/15 23:22, Sergey Beryozkin wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Markus, I'm not suggesting to redefine, I'm
>>>>>>>>>>> suggesting to make the way SSE is implemented in
>>>>>>>>>>> JAX-RS a little bit less technical as far as users
>>>>>>>>>>> working with it are concerned ?
>>>>>>>>>>> Re restricting to a single MT for all the events
>>>>>>>>>>> inside a single channel, is it a bad thing ? I'm not
>>>>>>>>>>> sure. We can always assume that in theory it is
>>>>>>>>>>> possible, but lets face it, I doubt anyone can come
>>>>>>>>>>> up with a practical example where multiple MTs are
>>>>>>>>>>> mixed in. In fact supporting per-event MT can be
>>>>>>>>>>> added later on at a builder level if such a freedom
>>>>>>>>>>> of formatting is ever needed...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Cheers, Sergey
>>>>>>>>>>> On 27/10/15 22:32, Markus KARG wrote:
>>>>>>>>>>>
>>>>>>>>>>> But Sergey, we only should define an API how SSE
>>>>>>>>>>> can be mapped upon JAX-RS. We cannot redefine
>>>>>>>>>>> how SSE works. And it is simply the W3C that
>>>>>>>>>>> defined that SSE is initiated by sending that
>>>>>>>>>>> particular MT and that each single event can
>>>>>>>>>>> definitively have different entity type. What
>>>>>>>>>>> you propose certainly looks more familiar, but
>>>>>>>>>>> would redefine the W3C-defined semantics of SSE.
>>>>>>>>>>> *From:*Sergey Beryozkin
>>>>>>>>>>> [mailto:sberyozkin_at_talend.com]
>>>>>>>>>>> *Sent:*Dienstag, 27. Oktober 2015 23:25
>>>>>>>>>>> *To:*jsr370-experts_at_jax-rs-spec.java.net
>>>>>>>>>>> *Subject:*Re: [jax-rs-spec users] SSE Draft
>>>>>>>>>>> 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> 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>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?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>