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