see section "3.4.2. Provider Priorities" in wink documentation "...uses the priority as the last sorting key for providers of equal standing"
From: Michael Rheinheimer [mailto:[email protected]] Sent: Tuesday, September 22, 2009 10:31 PM To: [email protected] Subject: Re: [DISCUSS] priority sort key as override for Providers? Hi, Treating it as a tie-breaker is fine with me. If that's the consensus, I'll go re-work the patches in WINK-193 and WINK-167 to use priority param as a tie-breaker and integrate Bryant's suggestions. I won't be able to get to it until Friday, though, as I'm on vacation the next two days. Thanks.. mike [cid:[email protected]]Bryant Luk ---09/22/2009 01:55:47 PM---I think there should be a clear distinction in Wink provider priority from default (system) provider From: Bryant Luk <[email protected]> To: [email protected] Date: 09/22/2009 01:55 PM Subject: Re: [DISCUSS] priority sort key as override for Providers? ________________________________ I think there should be a clear distinction in Wink provider priority from default (system) providers versus user added ones (whether priority is defined as a tie-breaker or an override). For the ones added automatically via wink-providers,I would prefer somewhere in-between default system ones and explicitly user-added ones in the JAX-RS Application subclass and any other config registration system. I think this would allow users to drop in wink-provider JARs if they want to override the defaults while still respecting the programmatic config. On Tue, Sep 22, 2009 at 12:50 PM, Michael Elman <[email protected]> wrote: > Originally it was designed as a "tie-breaker". > > > On Tue, Sep 22, 2009 at 8:37 PM, Michael Rheinheimer <[email protected]>wrote: > >> >> >> Hi team, >> >> We have a double 'priority' param that can be passed to some of the >> ProvidersRegistry.addProvider methods. This is a non-spec key, thus a WINK >> feature. Given that, I've been treating it as an "override" rather than a >> "tie-breaker" when sorting Provider priority. For example, if a user >> specifies ContextResolver1 that @Produces("text/*") and a ContextResolver2 >> that @Produces("text/xml") and adds them to the ProvidersRegistry as such: >> >> addProvider(ContextResolver1, 5); >> addProvider(ContextResolver2, 0); >> >> Even though ContextResolver2 would be a closer match for media type >> "text/xml", ContextResolver1 would be favored due to the higher declared >> priority. Any thoughts on this? >> >> If we all agree, I think we have some work to do around supporting this >> priority feature; making sure the user knows what the default system >> provider priority is, perhaps issuing warnings when the priority of their >> provider is the same as the system default or negative, adding tests, >> optimizing code paths in ProvidersRegistry, etc. >> >> Please see patch in WINK-193 (this being the more informative) and WINK-167 >> (which is easier to see how the priority would be used as an override). >> >> Thanks.. >> mike > -- - Bryant Luk
