Topics

Proposed Final Draft


Pavel Bucek
 

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


 

jaxrs-2_1-pfd-api.zip\javax.ws.rs-api-2.1-m09-sources.jar contains module-info.java. Is that by intention? I thought you wanted to omit that due that Java 9 not being final?

-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Donnerstag, 22. Juni 2017 13:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] Proposed Final Draft

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


Andy McCright
 

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



 
 


Pavel Bucek
 

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



 
 



Andy McCright
 

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




 
 
 
 


Pavel Bucek
 

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




 
 
 
 



Sergey Beryozkin
 

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




 
 
 
 




Pavel Bucek
 

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




 
 
 
 





Sergey Beryozkin
 

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




 
 
 
 






Pavel Bucek
 

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




 
 
 
 







Sergey Beryozkin
 

I thought I'd check the docs first before asking, and obviously I missed this one:

https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/client/ClientBuilder.java#L275

:-)

Thanks, Sergey

On 11/07/17 11:59, Pavel Bucek wrote:

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