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