Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

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 -

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,