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