Hi Pavel I thought that the MVC spec was shipping its own default mapper, that is way I was suggesting checking javax.*. if it is not the case then I agree it would not work

That is the main use case AFICT. Any library/framework sitting on top of JAX-RS may need finer control over this. @Priority is already used for filters and interceptors, except that in this case the

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

Hi Santiago In what other cases, apart from ensuring a mapper shipped with MVC (or other spec APIs depending on JAX-RS), we would want to support sorting two

By an annotation you mean something like @PreferBuiltinProviders? I don’t see how that addresses the requirements outlined in JIRA 537. — Santiago

I guess that what I also suggested when we talked with Christian about @DefaultProvider - the only problem from what I understood MVC will've been already released by the time JAX-RS 2.1 gets out. To

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,

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

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,

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

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

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

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

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"

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

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

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

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

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.

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