Hi Markus
Well, thanks for keeping commenting, and while I'm tempted to give up,
I'll keep replying just for the sake of making sure that what I
suggested is at least clearly understood, and given your comments, it is
not, which is entirely my fault as I'm failing to explain..., so
On 11/11/15 17:39, Markus KARG wrote:
>
> First, you added a special annotation for the sole purpose of SSE.
> Oracle's proposal simply used the existing solution to cover this case
> without adding any special functionality.
>
Look at the signature of the sample code posted by Marek (I do like what
he prototyped and what I'm talking about here is arguably an
optimization). So a method returns an SSE handler which (I'm sorry if
I'm wrong) is responsible for formatting the overall output payload on
the per-even basis, including I guess sticking text/sse-stream.
In JAX-RS 1) @Produces affects does the intersection and the final
response CT - 2) which affects the selection of MessageBodyWriter - 3)
which formats the response data.
I agree @Produces(text/sse-stream) can be used to intersect - but it is
not affecting the selection of MBW for the purpose of formatting the
overall response.
So I'd say neither proposal reusing the existing solution.
So what I suggested is to keep using @Produces for selecting MBW for
formatting indiv event data pieces. @SSEProduces was a 'response' to
Santiago comments, and the idea there is to make it obvious that there
are two Media Types which are in play here, one is text/event-stream -
which is a MT for the overall SSE response, and another MT - the one
needed to select a MessageBodyWriter for formatting the event data pieces
>
> Second, your proposal fixes the content type of all events to be the
> same, while Oracle's proposal did not.
>
I don't believe you keep saying it about my proposal :-).
I'm sure you know, without SSE, when we have
@Produces("application/json")
@GET
public Book getBook() {
return Response.ok(new Book()).type("application/xml").build();
}
the final CT to be used for selecting MBW is "application/xml". I.e, if
the application code does not set "application/xml" then the default
application/json is set, but the application can override it.
This is exactly what I suggested:
@Produces("application/json")
@SseProduces
public SseOutputChannel get() {
// set MT for a given event to application/bar
}
or
@SseProduces
@Produces("application/json")
public SseOutputChannel get() {
// all events data are JSON - why set it for every event if non-SSE
users can avoid doing by having @Produces ?
}
or
@SseProduces
public SseOutputChannel get() {
// all events data MTs are set individually
}
However I'm agreeing that
'_at_SseProduces' is a special approach. Hmm...
So what can be done to make this (non SSE)
@Produces("application/json")
@GET
public Book getBook() {
return Response.ok(new Book()).build();
}
where a user does not have to set a type on every response working for
SSE too ?
By the way, Marek are you interested at all in discussing it :-) ? I
know it is been in Jersey for nearly a year now so may it is all already
written in stone and no point spending time on discussing it further...
Thanks, Sergey
> -Markus
>
> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> *Sent:* Dienstag, 10. November 2015 22:16
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> *Subject:* Re: [jax-rs-spec users] SSE Draft
>
> I guess this is one of those cases when one fails to convey the
> message despite trying...How what I suggested is a 'special case' of
> SSE while all I tried was to actually avoid having SSE putting its
> foot into a JAX-RS approach is beyond me...
>
> Sergey
> On 10/11/15 17:37, Markus KARG wrote:
>
> The difference is that Marek and Santiago's original proposal
> actually is a /generic/ 1:1 mapping of W3C's SSL data type on
> JAX-RS, while yours is a completely /special case/ for SSE.
>
> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> *Sent:* Dienstag, 10. November 2015 15:58
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> <mailto:jsr370-experts_at_jax-rs-spec.java.net>
> *Subject:* Re: [jax-rs-spec users] SSE Draft
>
> 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”}
>
>
>
> 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
> <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
> <mailto: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
> <mailto: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
> <mailto: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
> <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
> <mailto: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?
>
>
>
>
>
>