> 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 <sberyoz...@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 <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/ >
