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).

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 explici

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 t

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 already do have them implemente

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 iss

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 are covered by chapter 4.3.

Hi Dennis, thanks for the pull request; please don't hijack the topic - this one is about client proxy support. Feel free to start a new thread. Regards, Pavel

Hi Sergey, ad 1) the response processing will be done on the caller (completer) thread (so, completionStage#whenComplete(..), not #whenCompleteAsync(..)), simply because it works in a same way as when

Dear experts, we are working on improving integration with BeanValidation [1], and seems like if we choose to address this issue, the change will be slightly bigger than I anticipated. In short, the i

We are still not exactly sure how / whether it should be put into place. JAX-RS implementation has to have list of supported locales, because there is a defined algorithm, which chooses effective loca

Hi Sergey, others, you suggest that the exception mapper would be part of MVC spec (not the implementation, so not in javax.* package but more like org.impl.something.*?). I think that checking packag

Hi Sergey, please see inline. yes, exactly. I was trying to offer another point of view on that issue, seemed like you are suggesting that the proposal uses @Priority in a way that contradicts its pur

Hi Andy, Dennis, proxy port and proxy host can be already be defined by java property (http.proxyHost and http.proxyPort). I'm not sure whether we can add proxy auth schemes at this point - if we'd st

Hi Sergey, Andy, Dennis, all, it would definitely make sense, but there are always issues when you need to provide credentials. Since JAX-RS client is generally an object, which should be retained for

selecting a right locale might be problematic. Imagine you have two resource method, one serving orders and the other one items. Items can be returned in different set of languages than orders. Then,

Hi Sergey, I recall getting a requests for supporting NTLM/Kerberos and maybe one other scheme - something related to ldap.. Regards, Pavel

FYI: Custom providers without @Provider annotation will have priority value javax.ws.rs.Priorities.USER (value 5000). Also, Priority(100) > Prority(500), so provider with Priority(100) will be process

Hi Christian. Yes, you are right, that's a "typo". Thanks for letting us know :) Regards, Pavel

Dear experts, we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method. I know that we already had a

The issue with Sync/Async/RxInvoker#patch methods is similar to what we do have with Sync/Async/RxInvoker#method, but surprisingly #method doesn't mention anything about unsupported HTTP methods or ru