Continuing with the idea of the special treatment of the providers shipped with the spec implementations. Rather than pursue a @DefaultProvider idea, how about treating the providers

Hi Christian Thanks too, I agree using @Priority is a viable option. But as I implied earlier, this approach (apart from solving the issue shown with MVC vs custom CSRF mapper)

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 Pavel, I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way. Regards Dennis

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

I agree. Naturally, user-defined providers should take precedence over built-in ones. Clearly, this statement is implicit rather than explicit and should be clarified —at least for some providers.

Priority should only be used to break ties. Certain providers have well-defined selection algorithms, but in some cases the final set is not a singleton. — Santiago

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.

Hi Pavel Where would usually the code wishing to pass the Locale get the list of supported locales from, without even getting JAX-RS involved ? If there was some

Sounds good. On the other hand, we simply could say that a Java EE 8 Full Product MUST use the Managed Executor Service, other Java EE 8 Non-Full-Product Profiles SHOULD use the Managed Executor

A JAX-RS application produces machine-readable information (XML, JSON, etc.), hence it does not support ANY human language by definition. BV provides machine-readable ConstraintViolations for this

We should not mix up concerns here. @Priority should only beak tie. Whether or not to choose built-in vs. application-provided should be separately declarable. For example, in case A it might make

Won't that work what I proposed in the issue tracker: Giving it a second thought I wonder whether Servlet's AsyncContext wouldn't provide what I proposed originally: A handle to the "original"

Bean Validation spec lead here, thanks a lot for considering this feature! > Since there is no way how to get a list of supported locales Why is it that you need to get the list of locales? The Locale

Hi Gunnar, Other than message interpolation, is there any other scenario where locale information is important in BV? What comes to mind is a string that contains a representation of a

Hi Markus, The precedence of application-defined vs. built-in providers has already been established and cannot be changed at this point (but should be clarified better as mentioned by others).

I do not see that we cannot change this. If we decide that a new, optional annotation will modify the precedence, this would be perfectly backwards compatible, as all non-annotated code will still

If we want to support I18N on the JAX-RS server, it only would be straightforward to not only translation BV messages, but we also have to provide similar services to ALL providers, too. For example,

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

Can those providers which need it, ex, BV exception mappers, depend on the existing injectable Configuration interface to ensure the locales or other info can be accessed in a portable way ? Cheers,