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 anywhere, write a blog post, speak about JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available on java.net promoted maven repository [1]; it will be soon released to maven central.

Best regards,
Pavel & Santiago

[1] https://maven.java.net/content/repositories/promoted/

----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: [jaxrs] JAX-RS 2.1 released!
Date: Thu, Aug 24, 2017 8:46 AM
 

Dear experts,

it's our pleasure to announce that JAX-RS 2.1 was officially released,
see https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jcp.org_en_jsr_detail-3Fid-3D370&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=UpdfB_BfG8Sfl9U7cu9zlMnzlZDpNORv4F5g8rYfZJg&m=cZRJPetic6K09SdI_u-Jjc-vHS2H3QnR0SDXEgGOdhk&s=SnEzQLU5tNb8MPU6q7EUqR7Urx_49nRhVFCRTExYWHk&e= .

Thanks everyone for participating!

Feel free to share this message anywhere, write a blog post, speak about
JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available
on java.net promoted maven repository [1]; it will be soon released to
maven central.

Best regards,
Pavel & Santiago

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.java.net_content_repositories_promoted_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=UpdfB_BfG8Sfl9U7cu9zlMnzlZDpNORv4F5g8rYfZJg&m=cZRJPetic6K09SdI_u-Jjc-vHS2H3QnR0SDXEgGOdhk&s=3nZn6wFCEZLLEl0zfP93CIwMNcsZvlxR8bao3NSDgVc&e= 



 

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 something which is not defined by the specification and JAX-RS user can't rely on this to work everywhere.

// and I'm certainly not saying that we won't do something like that for Jersey :)

Thanks and regards,
Pavel

Hi Pavel

FYI, in CXF returning Observable will be handled similarly to returning CompletionStage

Cheers, Sergey
On 22/08/17 09:06, Pavel Bucek wrote:

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 there is nothing like you mentioned there, so I don't think that the usecase you described is supported - returned Observable (or any other type) will be processed as any other type, so the pipeline will be triggered right after the object is returned from the resource method.

Returning CompletionStage is equal to invoking AsyncResponse#resume in CompletionStage#whenComplete callback, nothing more, nothing less..

Regards,
Pavel

 

On 18/08/2017 17:23, Markus KARG wrote:

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus

 

 

Hi Pavel

FYI, in CXF returning Observable will be handled similarly to returning CompletionStage

Cheers, Sergey
On 22/08/17 09:06, Pavel Bucek wrote:

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 there is nothing like you mentioned there, so I don't think that the usecase you described is supported - returned Observable (or any other type) will be processed as any other type, so the pipeline will be triggered right after the object is returned from the resource method.

Returning CompletionStage is equal to invoking AsyncResponse#resume in CompletionStage#whenComplete callback, nothing more, nothing less..

Regards,
Pavel

On 18/08/2017 17:23, Markus KARG wrote:

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus

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 there is nothing like you mentioned there, so I don't think that the usecase you described is supported - returned Observable (or any other type) will be processed as any other type, so the pipeline will be triggered right after the object is returned from the resource method.

Returning CompletionStage is equal to invoking AsyncResponse#resume in CompletionStage#whenComplete callback, nothing more, nothing less..

Regards,
Pavel

On 18/08/2017 17:23, Markus KARG wrote:

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus

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/javax/ws/rs/javax.ws.rs-api/2.1/

Regards,
Pavel


On 04/08/2017 15:36, Pavel Bucek wrote:

Hi Sergey,

it will be .. soon. I'm aiming for today / this weekend.

Regards,
Pavel

On 04/08/2017 14:46, Sergey Beryozkin wrote:

Hi Pavel

When will the final API be published to Maven Central ?
31 July was the finish of the Final Approval Ballot

Thanks, Sergey

Hi Sergey,

it will be .. soon. I'm aiming for today / this weekend.

Regards,
Pavel

On 04/08/2017 14:46, Sergey Beryozkin wrote:

Hi Pavel

When will the final API be published to Maven Central ?
31 July was the finish of the Final Approval Ballot

Thanks, Sergey

Hi Pavel

When will the final API be published to Maven Central ?
31 July was the finish of the Final Approval Ballot

Thanks, Sergey

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

On 11/07/2017 12:52, Sergey Beryozkin wrote:

Hi Pavel, thanks,

OK, what about the ScheduledExecutorService - how can the client API implementation know when to use this one
if the ExecutorService is also set ?

Cheers, Sergey

On 11/07/17 10:12, Pavel Bucek wrote:

Hi Sergey,

yes, that is correct.

Regards,
Pavel

On 11/07/2017 10:35, Sergey Beryozkin wrote:

Hi Pavel

These executor services, if set in the client builder - should they be used in the rx() flows ?

Thanks, Sergey 
On 11/07/17 00:12, Pavel Bucek wrote:

Hi Andy,

firstly, thanks for your kind words.

Your pull request was merged - good that you brought that up. Thanks!

Best regards,
Pavel

On 07/07/2017 14:38, Andy McCright wrote:

Hi Pavel,

 

Thank you for the clarification, and my apologies for bringing this up so late - a colleague and I ran into some confusion on this point, so I thought I would bring if forward in hopes that other users might avoid a similar confusion.

 

I have opened a pull request [1] with my suggested changes to the javadoc.  I think this may help users better understand the differences in the Java SE vs EE environments.

 

Thanks again - it has been a pleasure working with you in this expert group!

 

Andy

 

[1] https://github.com/jax-rs/api/pull/560

J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...

 

 

----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Proposed Final Draft
Date: Fri, Jul 7, 2017 12:25 AM
 

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.

The "default" for Java SE is NOT ForkJoinPool#commonPool, since it is not meant for I/O operations. On Java SE, the default is intentionally left as implementation specific.

And I'm not sure what you mean by "what about Future Objects returned from ..." - if there is any need for starting a thread, it should be done on the executor service provided in the client builder. Note that the javadoc for ClientBuilder#executorService mentions:

* Provided executor service will be used for executing asynchronous tasks.

And Invocation#buildGet() (and others):

* Submit the request for an asynchronous invocation and receive a future
* response back.

Which seem to imply what I wrote..

It might be still possible to tweak the javadoc, I'll wait for your reaction - whether this makes sense or not and then will inquire about possible javadoc adjustment.

Thanks and regards,
Pavel

On 07/07/2017 00:35, Andy McCright wrote:

Hi Pavel,

 

If it is not too late, I'm wondering if we could clarify the uses of ClientBuilder.executorService(...) and scheduledExecutorService(...).

 

Are we saying that in a Java EE environment, these methods have no effect?  If so, can we change this text:

When running in a Java EE container, implementations are required to use the container-managed executor service.

 

to:

When running in a Java EE container, this method will have no effect.  The container will always use the container-managed executor service.

 

and a similar change for the executorService method?

 

 

If instead we are saying that in a Java EE container, the default ES and SES are different than in Java SE, we should clarify it like this:

When running in a Java EE container, the default scheduled executor service will be the container-managed service.  In Java SE, this will be the ForkJoinPool service.

 

 

I think we should also clarify what methods will use these services.  The javadoc currently provides some guidance with:

     * @see Invocation.Builder#async()
     * @see Invocation.Builder#rx()
     * @see RxInvokerProvider#getRxInvoker(SyncInvoker, ExecutorService)

and

     * @see SseEventSource.Builder#reconnectingEvery(long, TimeUnit)

 

but what about Future objects returned from methods like buildGet().submit(...)?

 

Thanks,

 

Andy

 

J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...

 

 

----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: [jaxrs] Proposed Final Draft
Date: Thu, Jun 22, 2017 6:18 AM
 

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.

Thanks and regards,
Pavel & Santiago

[1] https://jcp.org/en/jsr/detail?id=370