At some point, user-registered providers were always preferred over the
equal built-in providers before even starting the selection,, but
eventually, after the TCK failures and long discussions, it proved CXF
was not compliant at a time. Thus, first, the built in and
user-registered providers are mixed in, and the various spec conditions
are applied, and only then, if a user-provided provider and a built-in
provider are 2 equal candidates, then the user-provided one wins
Sergey
On 18/12/17 09:39, Sergey Beryozkin wrote:
What exactly is falling down ?
Sergey
On 17/12/17 21:46, John D. Ament wrote:
I figured out where its falling down. If you look at the class
ProviderInfoClassComparator in ProviderFactory, it handles sort the
provider infos with the custom attribute set.
The problem is that the actual provider sorting is done on the built
lists. They're not provider infos, just the instances of the
providers. I guess the provider infos can be passed around, but the
way they're determined is out of sync.
John
On 2017-12-17 14:46, Andy McCright <[email protected]> wrote:
John,
There is also a setUserProviders(...) method (possibly in the base
ProviderFactory class) - that method should set the custom boolean to
true
in the ProviderInfo object and should sort them ahead of the built-in
providers.
Even so, I like the idea of setting a MAX_INT priority on the built-in
providers - that would definitely prevent them from being selected over
user-specified providers.
Thanks,
Andy
On Sun, Dec 17, 2017 at 8:42 AM John D. Ament <[email protected]>
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 <[email protected]> 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 <
[email protected]>
wrote:
Le 16 déc. 2017 20:28, "Andy McCright"
<[email protected]> 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
<[email protected]>
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
