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 <sberyoz...@gmail.com> wrote:
Which default providers are you referring to ?
If it is MBR or MBW then their priority is implicit, based on the spec
text re how to sort media types, etc.
Sergey
On 17/12/17 14:42, John D. Ament wrote:
FWIW, I had assumed I was doing something wrong. However, I'm just
delegating down to ClientProviderFactory.setProviders, which does
pass in custom as false for the built in providers (look at
ProviderFactory#L142).
I'm inclined to align with Romain's thinking, we should just set a
high priority on the built in providers, to avoid any conflicts. I
already did this to register the Json P provider. This would more
easily allow consuming frameworks to add their own providers of
slightly higher priorities.
John
On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com>
wrote:
True - we would also need to add default priority to the
user-specified
providers (‘Priorities.USER’).
On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau
<rmannibu...@gmail.com>
wrote:
Le 16 déc. 2017 20:28, "Andy McCright"
<j.andrew.mccri...@gmail.com> a
écrit :
I don’t have the code in front of me, but I remember that
for JAX-RS
providers there was a check for a
“userâ€Â/“custom†boolean - the built-in
providers are false, user providers (regardless of priority) are
true.
That boolean is checked before the ‘@Priority’
annotation.
With the new emphasis on using ‘@Priority’ in the
JAX-RS 2.1 spec, we could
probably simplify the code (and possibly speed up the sorting
logic) if we
got rid of the special booleans and set
‘@Priority(Integer.MAX_VALUE)’ for
all built-in providers.
This is not forbidden by the spec so we still need a flag to let
the user
overriding cxf defaults, no? (Unlikely doesnt mean never, libs
will have
the same idea i guess, in particular for generic providers)
On Sat, Dec 16, 2017 at 12:55 PM John D. Ament
<johndam...@apache.org>
wrote:
The JAX-RS spec mandates a certain number of providers by
default. I'm
noticing that when these providers are added, they're added
without any
priority. Andy mentioned to me that they should be added with the
priority
of USER + 1, but the actual resolved priority I'm seeing is USER.
Granted, this is within the proxy client code base. Is this
problem
going
to exist as well in the regular clients? As well as server?
If so, should we annotate them with USER + 1 to avoid the issue?
John
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
