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?

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

Hi Jim, We’ll have to wait until the e-mail migration is completed to look at the original thread. I can’t recall if this particular pattern was explored. Generally, however, a provider in

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

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

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

Dear experts, there is couple of filed issues related to provider ordering, namely: https://github.com/jax-rs/api/issues/538 https://github.com/jax-rs/api/issues/537 We

Dear experts, as we already stated, we'd like to support returning CompletionStage from the resource mehod, corresponding spec issue is here: https://github.com/jax-rs/api/issues/551 The only open

Hi, Have you considered how this will behave when the provider is a CDI @Alternative or @Stereotype? I'm unsure how much those could interfere but I think it's something to take into account

Hi all, It might be too late to add this (if so, no worries), but I've been running into a few customer situations where customers are using HTTP/HTTPS proxy servers with their JAX-RS client APIs.

Hi everyone, I'm very happy to see that the issue of provider ordering is addressed in the upcoming JAX-RS release. Thanks a lot for your work on that. I would like to point the EG to a discussion

Hi Christian, see chapter 4.2.4: Which i s the base of what I mentioned - there is one issue though - this is only about entity providers, not about ExceptionMappers, which

Hi, I was writing to propose exactly that. That's be the more flexible approach, and would resolve my open question about what exactly is a built-in provider

Hi, in my view there should be at least standardized constants for the properties in 2.1. I created a PR for the timeout stuff yesterday: https://github.com/jax-rs/api/pull/555 These properties can

Hey Pavel, thanks a lot for your quick reply. Thanks a lot for pointing me to section 4.2.4. But as you already wrote the current version of this statement just covers entity providers. I would be

Hi Pavel Not sure it is relevant but it is not exactly the case with MessageBodyReader/Writers where the custom providers can still lose to built-in providers. By

Hi Pavel I'd leave it up to the implementation to decide. The other thing I was thinking about. On the client side we have RxInvoker which supports not only CompletableFuture. Should we have

Hi Sergey, Of course nobody will want to create two ExceptionMapper<MyObject> implementations in his application. It is more about the case that some framework provides a "default" exception mapper

Hi Christian Right, do you mean that both of these providers are custom as far as the JAX-RS implementation is concerned ? Sure, I see what you mean now. I

Hey Sergey, thanks for your quick reply. Yes, exactly. In this case JAX-RS currently doesn't specify which one should be used. Not sure if something like @DefaultProvider is flexible enough. Maybe