You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cxf.apache.org by "John D. Ament" <jo...@apache.org> on 2017/12/16 18:55:39 UTC

Default Priority for built in providers

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

Re: Default Priority for built in providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Hi John,

It should already be the case but in another manner: with the bus flag. I'm
not sure client code got it anytime but rather than using a random number
(you never know if user code uses USER+xxx for its own fallbacks) then
using the bus -
https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/ProviderInfo.java#L31
-  is saner and means "CXF default". Wdyt?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2017-12-16 19:55 GMT+01:00 John D. Ament <jo...@apache.org>:

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

Re: Default Priority for built in providers

Posted by Sergey Beryozkin <sb...@gmail.com>.

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 <j....@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 <jo...@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....@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 <
>>>> rmannibucau@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Le 16 dÃ©c. 2017 20:28, "Andy McCright" 
>>>>>> <j....@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 
>>>>>> <jo...@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
> 
>

Re: Default Priority for built in providers

Posted by Sergey Beryozkin <sb...@gmail.com>.

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....@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 <jo...@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....@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 <
>>> rmannibucau@gmail.com>
>>>> wrote:
>>>>
>>>>> Le 16 dÃ©c. 2017 20:28, "Andy McCright" <j....@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 <jo...@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/

Re: Default Priority for built in providers

Posted by "John D. Ament" <jo...@apache.org>.

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....@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 <jo...@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....@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 <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Le 16 dÃ©c. 2017 20:28, "Andy McCright" <j....@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 <jo...@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
> > > > >
> > > >
> > >
> >
>

Re: Default Priority for built in providers

Posted by Andy McCright <j....@gmail.com>.

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 <jo...@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....@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 <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Le 16 déc. 2017 20:28, "Andy McCright" <j....@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 <jo...@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
> > > >
> > >
> >
>

Re: Default Priority for built in providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Le 20 déc. 2017 03:47, "John D. Ament" <jo...@apache.org> a écrit :

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.

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


How do you handle cases where containers ship them and user iverride ut to
use another impl? Custom=true or bus=true solves it smoothly whereas the
priority doesnt :(. Tomee, meecrowave are in that case to cite a few.


John

On 2017-12-19 10:17, Sergey Beryozkin <sb...@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 <sb...@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....@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
> >>>>>> <rm...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Le 16 dÃƒÂ©c. 2017 20:28, "Andy McCright"
> >>>>>>> <j....@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
> >>>>>>> <jo...@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/
>

Re: Default Priority for built in providers

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi John

Well, if we have the developers who are reading the spec then they will 
know the default priority is Priority.USER and can adjust accordingly.

I've just checked the spec, it has a new 4.1.3 section. That section 
first stresses that the pre-packaged provider should not be chosen over 
the equal application provider, and next it talks about how priorities 
can affect the (2) equal application providers.

Indeed, perhaps putting some large number on the built-in MBRs/MBWs 
won't harm. May be it just should be done. You are right we don't want 
the developers be unexpectedly 'surprised'.

IMHO though it would not be a bad idea to get at least a single case 
tested first where, without attaching these max values, we would see, 
yes, the user provider loses. As I implied earlier the selection 
algorithm should guarantee it never happens with respect to MBR/MBW, so 
if one gets such a test then the selection algorithm implementation will 
need to be reviewed...

I've just looked at the MBR and MBW comparators, the priority check is 
done after the custom flag is checked, so it does look very safe to me...

Sergey

On 20/12/17 23:33, John D. Ament wrote:
> Sergey,
> 
> Agreed, yes that's the current confusing part.  The problem is that the 500x default behavior is what's surprising to some users (having implemented it in CXF and other JAX-RS runtimes and received internal user feedback on what is and isn't working).  Granted, most devs don't read the JAX-RS spec and just blindly do, as a result everything ends up with the default priority and simply win as custom vs built in.
> 
> Then you get the craft dev that did read the spec, realizes that you can specify priority and suddenly the provider they registered isn't taken into account.  You know why? They added @Priority(6000) (higher value) instead of @Priority(4000) (lower value) expecting theirs to be picked up first.
> 
> So really the argument makes it so that giving everything a consistent priority would work a bit better than centering everything around 5000.
> 
> John
> 
> On 2017-12-20 05:48, Sergey Beryozkin <sb...@gmail.com> wrote:
>> 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 <sb...@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 <sb...@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....@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
>>>>>>>>>> <rm...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Le 16 dÃƒÆ’Ã†â€™Ãƒâ€šÃ‚Â©c. 2017 20:28, "Andy McCright"
>>>>>>>>>>> <j....@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
>>>>>>>>>>> <jo...@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/
>>>>
>>

Re: Default Priority for built in providers

Posted by "John D. Ament" <jo...@apache.org>.

Sergey,

Agreed, yes that's the current confusing part.  The problem is that the 500x default behavior is what's surprising to some users (having implemented it in CXF and other JAX-RS runtimes and received internal user feedback on what is and isn't working).  Granted, most devs don't read the JAX-RS spec and just blindly do, as a result everything ends up with the default priority and simply win as custom vs built in.

Then you get the craft dev that did read the spec, realizes that you can specify priority and suddenly the provider they registered isn't taken into account.  You know why? They added @Priority(6000) (higher value) instead of @Priority(4000) (lower value) expecting theirs to be picked up first.

So really the argument makes it so that giving everything a consistent priority would work a bit better than centering everything around 5000.

John

On 2017-12-20 05:48, Sergey Beryozkin <sb...@gmail.com> wrote: 
> 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 <sb...@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 <sb...@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....@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
> >>>>>>>> <rm...@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Le 16 dÃÆÃâÃâÃÂ©c. 2017 20:28, "Andy McCright"
> >>>>>>>>> <j....@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
> >>>>>>>>> <jo...@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/
> >>
>

Re: Default Priority for built in providers

Posted by Sergey Beryozkin <sb...@gmail.com>.

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 <sb...@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 <sb...@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....@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
>>>>>>>> <rm...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Le 16 dÃƒÆ’Ã‚Â©c. 2017 20:28, "Andy McCright"
>>>>>>>>> <j....@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
>>>>>>>>> <jo...@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/
>>

Re: Default Priority for built in providers

Posted by "John D. Ament" <jo...@apache.org>.

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.

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

John

On 2017-12-19 10:17, Sergey Beryozkin <sb...@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 <sb...@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....@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 
> >>>>>> <rm...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Le 16 dÃÆÃÂ©c. 2017 20:28, "Andy McCright" 
> >>>>>>> <j....@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 
> >>>>>>> <jo...@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/
>

Re: Default Priority for built in providers

Posted by Sergey Beryozkin <sb...@gmail.com>.

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 <sb...@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....@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 
>>>>>> <rm...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Le 16 dÃƒÂ©c. 2017 20:28, "Andy McCright" 
>>>>>>> <j....@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 
>>>>>>> <jo...@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/

Re: Default Priority for built in providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.

> since a user may want to register the built in providers with a different
priority; presently that is blocked.

this is not and you can and it will behave as expected if you register it
in your user providers but if you register it implicitly you have this
custom flag which allows to make it the fallback instead of a main
provider. This is the only way to respect the user conf and not get any
conflict with user providers.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2017-12-19 13:08 GMT+01:00 Sergey Beryozkin <sb...@gmail.com>:

> 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 <sb...@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....@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 <
>>>>>> rmannibucau@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Le 16 dÃƒÂ©c. 2017 20:28, "Andy McCright" <
>>>>>>> j.andrew.mccright@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 <
>>>>>>> johndament@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/
>

Re: Default Priority for built in providers

Posted by Sergey Beryozkin <sb...@gmail.com>.

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 <sb...@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....@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 
>>>>> <rm...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Le 16 dÃƒÂ©c. 2017 20:28, "Andy McCright" 
>>>>>> <j....@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 
>>>>>> <jo...@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/

Re: Default Priority for built in providers

Posted by Sergey Beryozkin <sb...@gmail.com>.

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 <sb...@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....@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 <rm...@gmail.com>
>>>> wrote:
>>>>
>>>>> Le 16 dÃƒÂ©c. 2017 20:28, "Andy McCright" <j....@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 <jo...@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/
>>

Re: Default Priority for built in providers

Posted by "John D. Ament" <jo...@apache.org>.

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 <sb...@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....@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 <rm...@gmail.com>
> >> wrote:
> >>
> >>> Le 16 dÃÂ©c. 2017 20:28, "Andy McCright" <j....@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 <jo...@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/
>

Re: Default Priority for built in providers

Posted by Sergey Beryozkin <sb...@gmail.com>.

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....@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 <rm...@gmail.com>
>> wrote:
>>
>>> Le 16 dÃ©c. 2017 20:28, "Andy McCright" <j....@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 <jo...@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/

Re: Default Priority for built in providers

Posted by "John D. Ament" <jo...@apache.org>.

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....@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 <rm...@gmail.com>
> wrote:
> 
> > Le 16 dÃ©c. 2017 20:28, "Andy McCright" <j....@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 <jo...@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
> > >
> >
>

Re: Default Priority for built in providers

Posted by Andy McCright <j....@gmail.com>.

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 <rm...@gmail.com>
wrote:

> Le 16 déc. 2017 20:28, "Andy McCright" <j....@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 <jo...@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
> >
>

Re: Default Priority for built in providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Le 16 déc. 2017 20:28, "Andy McCright" <j....@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 <jo...@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
>

Re: Default Priority for built in providers

Posted by Andy McCright <j....@gmail.com>.

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.

On Sat, Dec 16, 2017 at 12:55 PM John D. Ament <jo...@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
>