Dear experts,
after initial feedback, we decided to add a helper class -
SseClientSubscriber - to ease consumption of Server Sent Events on the
client side.
The simplest way how to register "event handler" only is now:
try (final SseEventSource eventSource = SseEventSource.target(target).build()) {
eventSource.subscribe(SseClientSubscriber.fromOnNext(System.out::println));
eventSource.open();
// ... }
We also chose to remove SseEventSource.Builder#open method, since the
API already provides this functionality (see SseEventSource#open()) and
having this on the builder as well could be confusing for some users.
Complete patch (including updated examples) is here:
https://github.com/jax-rs/api/commit/2ae0169a4da8d1af9861883fa3cf24709902af9c
Please let us know what you think.
Best regards,
Pavel
On 24/01/2017 20:54, Pavel Bucek wrote:
>
> Dear experts,
>
> please allow me to bring up another addition planned to be included in
> JAX-RS 2.1: Support for Server Sent Events.
>
> The API was introduced a while back [1], but we did incorporate some
> changes, mostly alignments with Java SE 8 and another one, slightly
> more controversial - alignment with Java SE 9 Flow API.
>
> Why we should use Flow API? We want to make the transition to Java 9
> as smooth as possible. Please note that today, the JAX-RS sources do
> contain Flow class (1:1 copy from Java SE 9), but that is NOT a final
> state. We want to work with it as much as possible, but we will
> minimize and clean up the code before final release. How? Consider
> following example:
>
> public interface SseBroadcasterextends AutoCloseable, Flow.Publisher<OutboundSseEvent> {
> //...
> }
>
> could be modified to
>
> public interface SseBroadcasterextends AutoCloseable {
> //...
> void subscribe(SseSubscriber<?super OutboundSseEvent> subscriber);
> }
>
> I hope you will like the attempt to be "forward-compatible", but I
> assume that this proposal alone will bring some opinions - please
> share them! Last note: currently, the Flow API is used only in SSE. We
> plan to use it heavily in Non-blocking I/O. If you think there are
> other areas where we can take advantage of Subscriber/Publisher
> methods, please let us know.
>
> Let me get back to the SSE API.
>
> Very brief description of the API is on the wiki [2], I will expand
> that once we'll have some feedback.
>
> The proposal contains support for server and client side. All classes
> are in the package javax.ws.rs.sse [3]. There is no added class from
> the last proposal, but there are some changes:
>
> - [server] SseBroadcaster extends Publisher<OutboundSseEvent>
> - [server] replaced SseBroadcaster.Listener by
> SseBroadcaster#onException and SseBroadcaster#onClose
> - [server] SseEventOutput extends Subscriber<OutboundSseEvent>
> - [client] SseEventSource extends Publisher<InboundSseEvent>
>
> Corresponding commit [4] looks like a bigger one, but most of it is
> renaming based on introduced interfaces, the core of the change is
> relatively small.
>
> I look forward to your comments and suggestions.
>
> I don't want to prolong this already too long email - please let me
> know if there are some areas which I should describe in more detail.
>
> Thanks and regards,
> Pavel & Santiago
>
> [1]
> https://java.net/projects/jax-rs-spec/lists/jsr370-experts/archive/2015-10/message/28
> [2] https://java.net/projects/jax-rs-spec/pages/ServerSentEvents
> [3]
> https://github.com/jax-rs/api/tree/master/jaxrs-api/src/main/java/javax/ws/rs/sse
> [4]
> https://github.com/jax-rs/api/commit/b2b8f3f4f20696558a3ff52b0de17fb04c343d02
>