see chapter 4.2.4:
An implementation MUST support application-provided entity
providers and MUST use those in preference to its own
pre-packaged providers when either could handle the same
request. More precisely, step 4 in Section 4.2.1 and step 5 in
Section 4.2.2 MUST prefer application-provided over
pre-packaged entity providers.
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.
I believe we could include more general statement in chapter 4,
which would say that application provided Providers have
priority over build-ins (and maybe define what build-in is) OR
we can say that implementation providers should have some
concrete priority set - which could be simpler than formally
defining built-in provider.
Santiago, others, what do you think?
On 21/05/2017 10:48, Christian
I'm very happy to see that
the issue of provider ordering is addressed in the
upcoming JAX-RS release. Thanks a lot for your work on
I would like to point the
EG to a discussion from one of the issues which was about
whether the priority ordering should be used only for
"custom providers" or for all providers (custom and
built-in providers). See  for details. During the discussion Pavel mentioned that JAX-RS
already mandates that custom providers are preferred over
built-in providers. I didn't find this anywhere in the
spec document, but maybe I just missed it.
The one thing that still
makes me think that the priority ordering should be used
for all providers is that the definition of "built-in
provider" is a bit blurry. What is a built-in provider?
What about providers which are deployed as app server
modules and therefore are provided out of the box by the
container? Are they built-in or custom providers? Perhaps
this should simply be clarified in the spec?
I would be happy to hear
about other opinions.