Yes, sorry, I was thinking only about resources. There is indeed an intersection. Returning resources from the configuration seems a bit strange, though, but ultimately is whatever we define it to be.

Pavel, Sergey, My recollection is that the Configuration#getClasses() is not related to resources, but only providers and features. So I think the results returned by the two #getClasses() mentioned s

+1 — Santiago

That's a good point, and certainly not something we can easily resolve. As others have mentioned, a strength of Java EE is integration with other specs like CDI, JSON-B, etc. But let us not forget tha

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 e

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

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

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 locale-specific

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

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

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 JAX-RS is a