Hi Santiago,
That Entity, it is in the .client subpackage.
Oh, do you refer to the custom helper ? Yes, I see what you mean.
Thanks, Sergey
On 06/02/17 15:06, Santiago Pericasgeertsen wrote:
> Hi Sergey,
>
> I understand where you are coming from. However, in my use the API in
> the past, what you bring up is almost never an issue because most of
> the time you end up using the specific methods in Entity for the
> correct media type.
>
> That is,
>
> event.data(json(myData)).build()
>
> which is arguably easier to read too. In fact, the same applies to
> traditional JAX-RS resources.
>
> I’m not sure about adding yet another annotation for this because of
> the existence of these easy-to-use methods.
>
> — Santiago
>> On Feb 6, 2017, at 7:13 AM, Sergey Beryozkin <sberyozkin_at_talend.com
>> <mailto:sberyozkin_at_talend.com>> wrote:
>>
>> 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
>>>>
>>>
>>
>>
>