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

From: Sergey Beryozkin <>
Date: Thu, 13 Mar 2014 10:40:29 +0000

Markus, All,

I've opened a 2.1 enhancement request:

I think it would be great to have a typed variant even without SSE

Thanks, Sergey

On 10/03/14 21: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
> 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