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
