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 <j.andrew.mccri...@gmail.com> 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 <johndam...@apache.org> 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/

Reply via email to