Date   

Re: ClientBuilder#executorService

Pavel Bucek
 

Hello,

good question, thanks.

Managed executor service references JSR 236 and I'd expect that when not present, the jndi lookup described in the spec would return null and jax-rs implementation will then fallback to "java se" case.

Thanks for pointing that out, I guess we'd need to rephrase the condition to something like "When JSR 236 is available, provided managed executor service has to be used as an executor service for asynchronous client calls."

Regards,
Pavel


On 18/05/2017 18:49, Guillermo González de Agüero wrote:
Hi,

Perhaps this is a naive question, but how is the "managed" executor service handled on the Web Profile? Does "managed" mean that it must use a JSR 236 executor, or does it just refer to any "container managed" one?

The Web Profile does not include JSR 236, hence my question.


Regards,

Guillermo González de Agüero

El jue., 18 de mayo de 2017 17:37, Pavel Bucek <pavel.bucek@...> escribió:
Dear experts,

please let me know if you find anything wrong with following statements:

on Java EE container:

     - JAX-RS client will use ManagedExecutorService for async/reactive
calls unless set explicitly by ClientBuilder#executorService

on Java SE:

     - JAX-RS client will use undefined, implementation specific
ExecutorService for async/reactive call, unless set explicitly by
ClientBuilder#executorService

Thanks,
Pavel






Re: ClientBuilder#executorService

Guillermo González de Agüero
 

Hi,

Perhaps this is a naive question, but how is the "managed" executor service handled on the Web Profile? Does "managed" mean that it must use a JSR 236 executor, or does it just refer to any "container managed" one?

The Web Profile does not include JSR 236, hence my question.


Regards,

Guillermo González de Agüero

El jue., 18 de mayo de 2017 17:37, Pavel Bucek <pavel.bucek@...> escribió:
Dear experts,

please let me know if you find anything wrong with following statements:

on Java EE container:

     - JAX-RS client will use ManagedExecutorService for async/reactive
calls unless set explicitly by ClientBuilder#executorService

on Java SE:

     - JAX-RS client will use undefined, implementation specific
ExecutorService for async/reactive call, unless set explicitly by
ClientBuilder#executorService

Thanks,
Pavel





ClientBuilder#executorService

Pavel Bucek
 

Dear experts,

please let me know if you find anything wrong with following statements:

on Java EE container:

- JAX-RS client will use ManagedExecutorService for async/reactive calls unless set explicitly by ClientBuilder#executorService

on Java SE:

- JAX-RS client will use undefined, implementation specific ExecutorService for async/reactive call, unless set explicitly by ClientBuilder#executorService

Thanks,
Pavel


Re: [jax-rs-spec users] RxInvokerProvider

Santiago Pericas-Geertsen
 

Hi Jim,

 We’ll have to wait until the e-mail migration is completed to look at the original thread.

On May 16, 2017, at 12:06 AM, Jim Ma <mail2jimma@...> wrote:

Hi Santiago, 
Before java.net is closed and all the archive emails are lost, I didn't finish going through all the traffic and find the archive email about this jave generic issue?  Can you please explain it again ?  
Does user creates provider and
instantiate invoker like following still have this generic issue ?
 
   public class CompletionStageRxInvokerProvider implements RxInvokerProvider<AnotherCompletionStageRxInvokerImpl> {
      public AnotherCompletionStageRxInvokerImpl getRxInvoker(SyncInvoker syncInvoker, ExecutorService executorService) {
          return new AnotherCompletionStageRxInvokerImpl(syncInvoker, executorService);
      }
   }

AnotherCompletionStageRxInvokerImpl invoker = builder.rx(new CompletionStageRxInvokerProvider())

 I can’t recall if this particular pattern was explored. Generally, however, a provider in JAX-RS is a type that is registered and not instantiated by application code. In fact, the default scope for providers is application scope. So the general idea is to instantiate it once and then use it many times to obtain whatever it provides (RxInvoker instances in this case). 

— Santiago


On Tue, May 9, 2017 at 9:19 PM, Santiago Pericas-Geertsen <santiago.pericasgeertsen@...> wrote:
Hi Jim,

 Once we introduced the notion of a provider to instantiate invokers, we run into a Java generics issue that we could not resolve (you can check the archives here [1]). The current solution was a bit of a compromise between requirements and type system capabilities.

— Santiago


On May 8, 2017, at 11:59 PM, Jim Ma <mail2jimma@...> wrote:

Hi, 
The new added RxInvokerProvider must be registered to the client using Client.register(Class) before create another reactive implementation invoker. Why do we need register to client first? Is it good that we simply change the Invocation.Builde#rx to 
   public <T extends RxInvoker> T rx(RxInvokerProvider<T> provider)
   {
      return provider.getRxInvoker(this, executorService);
   }
without register ? 

Thanks,
Jim




Re: JCP web page

Pavel Bucek
 

Hi Alessio,

the migration is still in progress, please be patient.

We don't have email archives ready (yet), the issues have been migrated to https://github.com/jax-rs/api/issues (as already stated). I'm currently not sure how/whether the webpage and wikis from java.net will be available, we'll keep you updated.

Sorry for any inconvenience.

Best regards,
Pavel


On 16/05/2017 12:01, asoldano@... wrote:

The https://jcp.org/en/jsr/detail?id=370 page has to be updated with proper links to discussion mailing lists, archives etc; can the EG lead please do that?




JCP web page

Alessio Soldano
 

The https://jcp.org/en/jsr/detail?id=370 page has to be updated with proper links to discussion mailing lists, archives etc; can the EG lead please do that?