I'm not keen to spend much time on this possible improvement, but I'll
summarize it here with the code example.
Typical JAX-RS (static):
// text/plain
@GET
@Produces("text/plain")
@GET
public Response getText() {
return Response.ok().entity("somedata").build();
}
Typical JAX-RS (overrides static):
// text/xml overrides text/plain
@GET
@Produces("text/plain")
public Response getText() {
return Response.ok().type("text/xml").entity("<somedata/>").build();
}
At this stage we know the users can override the static Produces if
needed, but let the static Produces affect the media type
if the user does not want to repeat the obvious "text/plain" in the code
In SSE, one can do something similar:
@GET
// this is a media type for the HTTP client which invoked this method
@Produces("text/plain")
// this is a media type for the OutboundEvent.Builder
@SSEProduces ("someMediaType")
public Response getText() {
// sse event without having to set a media type on the builder
// for the HTTP client
return Response.ok().type("text/xml").entity("<somedata/>").build();
}
The examples show the basic string data, assuming in most cases people
will want JSON, it would make sense to let the developes
just type something like @SSEProduces ("application/json") as opposed to
having them to do that on the builder every time.
This is arguably a minor improvement, possibly part of the higher-level
API idea...
Sergey
On 06/02/17 09:41, Sergey Beryozkin wrote:
> I do not remember us agreeing at all.
> You are referring to the media type required to initiate the flow, I'm
> referring to the one users have to set afterwards from the sse builders.
> And why exactly you can not set that statically if it what users would
> prefer if they always use the same type ?
>
> Sergey
> On 05/02/17 19:10, Markus KARG wrote:
>>
>> I can remember that thread and I thought we agreed that the current
>> proposal from Oracle is correct, because to initiate the SSE cannel
>> actually the @Produces defines the media type of SSE, not of the
>> message payloads. As all messages can have different payloads, IMHO
>> we cannot set the type statically.
>>
>> -Markus
>>
>> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
>> *Sent:* Sonntag, 5. Februar 2017 18:23
>> *To:* jsr370-experts_at_jax-rs-spec.java.net
>> *Subject:* Re: Server-Sent Events API proposal
>>
>> Hi Pavel
>> There was an issue I was trying to raise when the SSE draft was
>> originally proposed.
>> Specifically, it was about a default media type for SSE data.
>> Right now one needs to set a media type with the SSE builder. The
>> question was if we could let people use @Produces,
>> so that they do not set it every time an SSE data is returned,
>> similarly to the way it is done in the 'traditional' JAX-RS - one either
>> uses @Produces or uses Response to customize
>>
>> What do you think ?
>>
>> Thanks, Sergey
>> On 27/01/17 15:03, Sergey Beryozkin wrote:
>>
>> I've only glanced so far over the proposed changes, it all looks
>> very neat, but we will def provide more feedback later on.
>>
>> As far as Flow is concerned, is the idea to use it only as part
>> of SSE ? What will happen to it once the future JAX-RS API will
>> be Java 9-only based ?
>>
>> Cheers, Sergey
>>
>> On 27/01/17 14:54, Sergey Beryozkin wrote:
>>
>> Hi, I've been planning to move to m03 next week and see how
>> the latest reactive API fits,
>>
>> As far as SSE is concerned I've asked my colleague Andriy who
>> did implement the initial SSE proposal to evaluate the latest
>> one when he gets a chance and I will also have a look but
>> unlikely next week,
>>
>> I recall Andriy raised an issue on this list, something to do
>> with initializing SSE Broadcasters, Marek said at a time he
>> would look at it.
>>
>> Thanks, Sergey
>> On 27/01/17 07:55, Pavel Bucek wrote:
>>
>> No commends/feedback?
>>
>> I understand that the change is not a small one - feel
>> free to ask if you need to have something explained in
>> more detail.
>>
>> Please let me know if someone is planning to look into
>> this topic. Ideally by the end of this week (start of the
>> day Monday, CET). If there are no comments, we might need
>> to move it forward even without any other input, but I
>> don't really want to do that..
>>
>> Thanks and 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 *SseBroadcaster *extends *AutoCloseable,
>> Flow.Publisher<OutboundSseEvent> {
>>
>> ///.../
>>
>> }
>>
>> could be modified to
>>
>> *public interface *SseBroadcaster *extends *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
>>
>