Re: Default Priority for built in providers

[John D. Ament]

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