Re: Providers ordering

Santiago Pericas-Geertsen

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). Conceptually, we have two ordered sets and we only consider the built-in set iff the application-defined set is empty after filtering.

 In my view, the introduction of @Priority should only apply to application-defined providers —which are in fact the ones that developers can add annotations to.

— Santiago

On May 23, 2017, at 1:59 PM, Markus KARG <markus@...> wrote:

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 sense that an appliation provides a simplistic fallback provider just in case the JAX-RS implementation does not provide support for a particular feature (like PDF support for example). On the other hand, the application might want to provide a superior, really-expensive, full-monty provider for PDF, which shall always override a possible existing built-in one. This example showcases that it MUST be up to the application programmer to declare precedence. But I won't use @Priority for that. It should be a separate annotation.

Join to automatically receive all group messages.