I meant 'MBW' there...
Anyway, not a big deal whichever way it is finalized, but thinking
perhaps a minor optimization is possible
Sergey
On 08/11/15 17:52, Sergey Beryozkin 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)
> - @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.
>
> Hence I feel it is not perfect.
>
> Something like
>
> @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 <mailto: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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>