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