Re: Default Priority for built in providers

[Sergey Beryozkin]

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

Hi John

Thinking more about it, 

Re: Default Priority for built in providers

[John D. Ament]

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

Re: Default Priority for built in providers

[Sergey Beryozkin]

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

Re: Default Priority for built in providers

[Romain Manni-Bucau]

Le 20 déc. 2017 03:47, "John D. Ament"  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  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  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
> > 

Re: Default Priority for built in providers

[John D. Ament]

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

Re: Default Priority for built in providers

[Sergey Beryozkin]

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


wrote:

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

Re: Default Priority for built in providers

[Sergey Beryozkin]

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


wrote:

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


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

[Sergey Beryozkin]

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


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

[John D. Ament]

So I figured out most of the issue.  The problem was impacting all of the 
providers.

Here's basically what happened:

- The type of comparator you pass into setProviderComparator is unbounded, it 
takes any object.  But its only meant to sort ProviderInfo impls.
- There's a missing relationship between provider info and the contracts 
registered in JAX-RS.  To fix that in a typesafe client I added a new 
comparator that uses the contracts.  However I implemented it against the 
unbounded comparator you pass in.
- At one point, I was using this to directly sort the MicroProfile 
ResponseExceptionMapper impls as well, which have their own priority method.

So bottom line, I was able to get the sorting working properly, at least based 
on my understanding of the spec.  I do think it would be beneficial to set the 
built in providers with a very high priority and avoid configurations using the 
custom flag, since a user may want to register the built in providers with a 
different priority; presently that is blocked.

On 2017-12-18 04:38, Sergey Beryozkin  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  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 
> >> wrote:
> >>
> >>> Le 16 déc. 2017 20:28, "Andy McCright"  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 
> >>> 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

[Sergey Beryozkin]

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  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  
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  wrote:
True - we would also need to add default priority to the 
user-specified

providers (‘Priorities.USER’).

On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:

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


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

[Sergey Beryozkin]

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

True - we would also need to add default priority to the user-specified
providers (‘Priorities.USER’).

On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


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

[Sergey Beryozkin]

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


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

[John D. Ament]

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  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  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  wrote:
> > > True - we would also need to add default priority to the user-specified
> > > providers (‘Priorities.USER’).
> > >
> > > On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Le 16 déc. 2017 20:28, "Andy McCright"  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 
> > > > 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

[Andy McCright]

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  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  wrote:
> > True - we would also need to add default priority to the user-specified
> > providers (‘Priorities.USER’).
> >
> > On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Le 16 déc. 2017 20:28, "Andy McCright"  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 
> > > 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

[John D. Ament]

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

[Andy McCright]

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

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

[Romain Manni-Bucau]

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

[Andy McCright]

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

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn 

2017-12-16 19:55 GMT+01:00 John D. Ament :

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