[jax-rs-spec users] [jsr339-experts] Re: Adding SSE support to JAX-RS 2.1?

From: Sergey Beryozkin <>
Date: Tue, 25 Mar 2014 16:50:20 +0000

On 25/03/14 15:57, Marek Potociar wrote:
> On 10 Mar 2014, at 22:06, Sergey Beryozkin <
> <>> wrote:
>> On 10/03/14 20:42, Markus KARG wrote:
>>> I think adding support for SSE to JAX-RS would allow to standardize an
>>> API for a common type of application development problem: How to keep
>>> the client updated to server side changes?
>>> Example: Chat system.
>>> Common solution in JAX-RS 2.0: Any type of periodic GET (a.k.a polling
>>> et al), like
>>> @GET public java.util.List<CharComment> getChatComments() {
>>> return /* …all_chat_comments… */;
>>> }
>>> Possible solution with SSE: Get content of thread so far using initial
>>> GET, then wait for more thread postings using SSE (inversion of control
>>> regarding poll-vs-push).
>>> But clearly, I do not like the way Jersey proposes it. The API looks not
>>> very RESTful, it more looks like "Servlet++".
>>> Instead, if we decide to support SSE, we should concentrate on REST and
>>> only add that parts of API that still are RESTful and fit nicely into
>>> JAX-RS as it is designed currently.
>>> My proposal would be that the API should look like this:
>>> @GET *_at_WebSocket* public *java.util.Stream<*ChatComment*>*
>>> getChatComments() {
>>> return this.mySourceStream.filter(…).map(…);
>>> }
>> I think I really like it:
>> - use a dedicated annotation, the enabler, instead of overloading Produces
>> - Typed stream support; I was thinking yesterday more about
>> introdocing a typed StreamOutput variant. Jersey uses
>> EventOutputStream clearly usable in scope of SSE only, something like
>> what Markus suggests, that can be used with and without SSE, with
>> different data types, will do well
> In Jersey, the SSE EventOutput
> <> extends
> ChunkedOutput
> <><OutboundEvent
> <>>

Right... It's looking fine.
The only concern is the name 'ChunkedOutput' - it is not cool :-). I saw
references to it earlier, I thought it was to do with the HTTP chunked
encoding. IMHO StreamingResponse reads better, but I can drop it...

Other than that I'd only like to propose that something like
ChunkedOutput (StreamingResponse ?) can be used for non-partial complete
responses too as an alternative to StreamingOutput,

Meaning that the user should be able to write start/end tags (in
whatever format); right now, in CXF, I'm supporting it via
getEntityStream(), I thought a bit about having the explicit start/end
support but decided getEntityStream() can be simpler...But it's up for
the discussion, assuming the idea is supported


> ...
> Marek
>> Sergey
>>> This is aligned with Java EE 8's base platform which is Java SE 8,
>>> providingjava.util.Stream<T>as an endless pipeline of <T>events send by
>>> server. I assume anybody aware of the new Stream API will recognize what
>>> a method with such a signature will do: Provide not only a single
>>> ChatComment, but actually an endless stream. It is just a simple
>>> extension to what a GET does, actually only shifting the time when that
>>> GET ends -- defined by the client application. The @WebSocket annotation
>>> implies @SSEmuch in the same way as @GETimplies @HttpMethod, opening a
>>> way to extend from WebSockets to more SSE technologies (even @COMETor
>>> other legacy solutions). If JAX-RS provides support for SSE, then
>>> WebSockets is a MUST, since it seems to be the most "native" SSE
>>> extension to HTTP GET. My proposal obviously implies that there is some
>>> source stream injected which serves as the origin of the SSE events, and
>>> that the JAX-RS engine is utilizing ManagedExecutorServer (Java EE) or
>>> some unmanaged ExecutorService (Java SE). As an alternative, in Java EE
>>> environments, the source can be attached to CDI events, hence CDI's
>>> event dispatcher drives this chain.
>>> As you see, my proposal is much less defined around technical
>>> implementation, but much more around developer's readability and
>>> simplicity of the API. Also it is at-most aligned to Java 8. But
>>> certainly, it does not open doors for any fancy thing one could imagine
>>> with SSE channels in mind, but solely is defined to solve one clear
>>> RESTful problem: How to keep the client updated after an initial GET.
>>> And I think, that is the sole SSE item which has to be covered in a
>>> future RESTful API. Everything else, in my understanding, is not
>>> RESTful, hence is not necessarily to be covered by JAX-RS.
>>> Regards
>>> Markus
>>> *From:*Marek Potociar []
>>> *Sent:* Mittwoch, 5. März 2014 16:39
>>> *To:*
>>> <>
>>> *Subject:* [jsr339-experts] Adding SSE support to JAX-RS 2.1?
>>> Hello experts,
>>> As you may know, the first steps towards starting work on Java EE 8 has
>>> been made already. Among the most important ones was the Java EE 8
>>> Community Survey. As the survey results
>>> <>
>>> indicate,
>>> there is a very strong support in Java EE community for coming with a
>>> standard API for supporting Server-Sent Events in Java EE 8. Clearly,
>>> one way or the other, SSE support will be added in Java EE 8 platform.
>>> There are multiple options how to achieve this and one of these options
>>> being considered is to extend JAX-RS API to provide better support for
>>> SSE. Before we make a final decision, I'd like to get your feedback on
>>> whether or not you think that extending JAX-RS API with SSE support is a
>>> good idea.
>>> To get the idea how such JAX-RS API support could look like, please
>>> check Jersey User Guide section that describes how client and server SSE
>>> support is currently implemented in Jersey 2.x:
>>> I am looking forward to your feedback.
>>> Thank you,
>>> Marek

Sergey Beryozkin
Talend Community Coders