Hi John
On 20/12/17 02:47, John D. Ament wrote:
The only concrete case I can think of is when someone registers a MBR/MBW with
annotation priority of 5002 and up. In this case, the CXF provider will take
precedence. But as I understand the spec, the user
defined provider should always take precedence over the container created one.
It is a bit more complex, unfortunately. The way the current
(spec-compliant) selection algorithm works in CXF is that the user
provided provider will win, but only if it is at least equal to the
competing built-in provider.
For example, CXF has a built-in provider typed by String for reading
writing strings, with the wildcard Consumes. A user registered provider
typed by String will always win, but a custom provider typed by Object
and which is meant to read/write String as well will lose to the
built-in provider on the basis that Object is less specific then String,
before the priorities or the fact it is a user provider will even be
considered. (The property mentioned by Romain can be used to change it)
Another case. CXF ships JSONProvider which is Jettison based. It's not
technically a built-in JAX-RS provider, it is optional, just happens,
historically, CXF will auto-load it if it is available on the classpath,
So, if it is loaded, and Jackson is also loaded, Jackson will lose, why
?, because CXF JSONProvider has more specific media types better
matching something like application/json. The priorities will not be
even taken into consideration.
Etc...
Take for instance the one that ships with Johnzon or Jackson. There may be
cases where those providers should be used over the ones shipped by the JAX-RS
runtime. In fact, I would argue that if a JSON-B/JSON-P impl ships a JAX-RS
provider, we should use that provider over the one created by the JAX-RS
runtime (but that's just my opinion).
Both CXF JSONProvider (see above - vs Jackson) and the one shipped in
the CXF JSONP module (vs Johnson) are optional, they are not 'built-in',
as far as ProviderFactory is concerned, only the providers it registers
at the init time, before checking the user providers, are built-in ones.
What happens if, for example, a user adds a CXF JSONP module and Johnson
at the same time, which MessageBodyReader/writer will be selected ? I
don't know, that will need to be tested, I'd assume both providers have
exactly the same default priority though and both will be treated as
custom providers.
I feel the built-in providers (namely MBRs and MBWs) should have the
default priority, and it is up to the custom providers to ensure they
are selected first (have more specific Consumes or Produces, more
specific type, and if it ever comes to it - the right priority value).
Thanks, Sergey
John
On 2017-12-19 10:17, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
Hi John
Thinking more about it, adding some protection in the form of the max
priority to the built-in MBRs and MBWs will probably not harm, but it is
just difficult to see how it can practically help either, for now at least.
The existing selection algo should be sufficient to ensure the
absolutely equal user provider candidate prevails over the built in one.
There might be some cases I'm not aware of where the allocating of the
max priority values to the built-in ones can indeed help, but without
identifying such cases it can be also risky, hence I'd like us to come
up with such a case.
The extra sporting key in the form of the priority value can prob make
sense when 2 absolutely equal *user* providers are available, but to be
honest I can't even thing of the case where one would want to register
sat 2 MBRs with the same Consumes and the same Type but with different
priorities, it does not make much sense, the priority can help with
ordering the filters/interceptors, but in case of MBR/MBW where the
action affecting the streams is expected it is just to imagine...
Thanks, Sergey
On 19/12/17 12:08, Sergey Beryozkin wrote:
I'd like to avoid starting introducing the fixes against the problems
which might *not* be the actual problems, as far as the selection of
MBRs and
MBWs in the spec compliant manner is concerned
...
On 19/12/17 12:07, Sergey Beryozkin wrote:
Lets talk about some specific case. The only built in providers CXF
has are Message Body Reader and Writers. Well, there's a default
excpetion mapper there as well, but lets deal with it later.
So, giving these built-in MBRs and MBWs, lets have a look at a
specific case where you think having some high priority will matter,
example, describe some case where a user provider (with some type) is
registered and the current implementation is not sufficient to get
this user provider selected.
I'd like to avoid starting introducing the fixes against the problems
which might be the actual problems, as far as the selection of MBRs
and MBWs in the spec compliant manner is concerned
Thanks, Sergey
On 19/12/17 11:59, John D. Ament wrote:
So I figured out most of the issue. The problem was impacting all of
the providers.
Here's basically what happened:
- The type of comparator you pass into setProviderComparator is
unbounded, it takes any object. But its only meant to sort
ProviderInfo impls.
- There's a missing relationship between provider info and the
contracts registered in JAX-RS. To fix that in a typesafe client I
added a new comparator that uses the contracts. However I
implemented it against the unbounded comparator you pass in.
- At one point, I was using this to directly sort the MicroProfile
ResponseExceptionMapper impls as well, which have their own priority
method.
So bottom line, I was able to get the sorting working properly, at
least based on my understanding of the spec. I do think it would be
beneficial to set the built in providers with a very high priority
and avoid configurations using the custom flag, since a user may want
to register the built in providers with a different priority;
presently that is blocked.
On 2017-12-18 04:38, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
Which default providers are you referring to ?
If it is MBR or MBW then their priority is implicit, based on the spec
text re how to sort media types, etc.
Sergey
On 17/12/17 14:42, John D. Ament wrote:
FWIW, I had assumed I was doing something wrong. However, I'm just
delegating down to ClientProviderFactory.setProviders, which does
pass in custom as false for the built in providers (look at
ProviderFactory#L142).
I'm inclined to align with Romain's thinking, we should just set a
high priority on the built in providers, to avoid any conflicts. I
already did this to register the Json P provider. This would more
easily allow consuming frameworks to add their own providers of
slightly higher priorities.
John
On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com>
wrote:
True - we would also need to add default priority to the
user-specified
providers (‘Priorities.USER’).
On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau
<rmannibu...@gmail.com>
wrote:
Le 16 déc. 2017 20:28, "Andy McCright"
<j.andrew.mccri...@gmail.com> a
écrit :
I don’t have the code in front of me, but I remember that
for JAX-RS
providers there was a check for a
“userâ€ÂÂ/“customâ€ÂÂ
boolean - the built-in
providers are false, user providers (regardless of priority) are
true.
That boolean is checked before the ‘@Priority’
annotation.
With the new emphasis on using ‘@Priority’ in the
JAX-RS 2.1 spec, we could
probably simplify the code (and possibly speed up the sorting
logic) if we
got rid of the special booleans and set
‘@Priority(Integer.MAX_VALUE)’ for
all built-in providers.
This is not forbidden by the spec so we still need a flag to let
the user
overriding cxf defaults, no? (Unlikely doesnt mean never, libs
will have
the same idea i guess, in particular for generic providers)
On Sat, Dec 16, 2017 at 12:55 PM John D. Ament
<johndam...@apache.org>
wrote:
The JAX-RS spec mandates a certain number of providers by
default. I'm
noticing that when these providers are added, they're added
without any
priority. Andy mentioned to me that they should be added with the
priority
of USER + 1, but the actual resolved priority I'm seeing is USER.
Granted, this is within the proxy client code base. Is this
problem
going
to exist as well in the regular clients? As well as server?
If so, should we annotate them with USER + 1 to avoid the issue?
John
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
