Hi Rawand, MessageBodyReader and Writer are used in various contexts. For example, on server side, Reader is used to read request body. On the client side, Reader is used to read response body. Writer

Configuration is @since 2.0 Application#getClasses() is @since 1.0 I agree that Configuration#getClasses() should return complete config state of the app, so including automatically registered feature

I'd guess Configuration#getClasses() needs clarification. To be honest, for me, it mirrors Application#getClasses(), but on the runtime side (so I'd say that it can contain more classes than what Appl

Thanks Sergey and +1 to that statement ;)

Dear experts, it's our pleasure to announce that JAX-RS 2.1 was officially released, see https://www.jcp.org/en/jsr/detail?id=370. Thanks everyone for participating! Feel free to share this message an

Hi Sergey, I guess that's fine, unless someone registers MessageBodyWriter for Observable, which might then now work properly. I'm not saying that because I think that it shouldn't be done, its just s

Hi Markus, confirming what you wrote would be extending of what is pretty explicitly written in the spec, so I can't do that. Currently, the behavior is "defined" by what AsyncResponse provides and th

I'm sorry for the delay. I believe I'll be able release the API to be published to maven central today. (If you need it now, feel free to use: https://maven.java.net/content/repositories/promoted/java

Hi Sergey, it will be .. soon. I'm aiming for today / this weekend. Regards, Pavel

It should be used only for tasks which need to be scheduled. Effectively there is only single task like that in the API right now: delayed reconnect of SseEventSource. Regards, Pavel

Hi Sergey, yes, that is correct. Regards, Pavel

Hi Andy, firstly, thanks for your kind words. Your pull request was merged - good that you brought that up. Thanks! Best regards, Pavel

I have to agree, but we can't do the whole change at this point :-/ I'm adding @throws to Sse, since there is a default implementation in the api, which behaves like that. SseEventSink change could br

Annotating provider method arguments doesn't make much sense, since they are invoked by the implementation - declaring @throws makes more sense on methods which are invoked directly by the application

:-) $ grep -r IllegalArgument . ./javax/ws/rs/BadRequestException.java: * @throws IllegalArgumentException in case the status code set in the response ./javax/ws/rs/BadRequestException.java: * @throws

Well, if you look at the rest of the API, the pattern is to use IAE even when parameter is null, so .. being consistent with existing API wins over anything else..

Hi Markus, I'm sorry I'm responding so late, I must have missed this email. The main issue with Object.requireNonNull is that it throws a NPE instead of IAE, so we can't really use it on most of place

Hi Andy, it is very late for changing anything.. We are not saying that on Java EE environment ClientBuilder#executorService and #scheduledExecutorService have no effect - but it might sound that way.

Markus, yes, the issue is that mostly, you wouldn't want to mix "standard" response processing and SSE. MessageBodyWriter is slightly different, since there is a type, the ultimate definition of that

Dear experts, we'd like to announce that Proposed Final Draft was published on JCP JSR 370 page [1]. I'd like to encourage you all to review provided artifacts and let us know if you have any feedback