Just to give a heads up on a few changes I'm going to make. For the system providers, I think I'm going to make it very explicit that the system providers have a 0.1 priority. Due to the way the sorting worked, user providers were always chosen before system ones but they always had the same 0.5 priority on the server I believe. I think that's why Mike added his explicit setPriority code for the InnerApplication in his patch.
The other change is that I believe that user providers should always be chosen over system providers regardless of the C004 change. I believe Mike brought up a good point that a user provided MessageBodyWriter<Object> versus a system MessageBodyWriter<String> should call the user MessageBodyWriter<Object>.isWritable() before calling the system one. I'll "abuse" the priority system to fix this for now so that anything below 0.2 priority is a "system" provider that will be sorted later than "user" providers above 0.2 but perhaps this should be fixed differently. On Wed, Sep 23, 2009 at 1:57 AM, Michael Elman <[email protected]> wrote: > Currently I've implemented that system providers and the ones located using > wink-application has the same low (0.1) priority. > It can be changed that system providers have 0.1 priority and > wink-application have 0.2 priority, while the default priority is 0.5. > > On Tue, Sep 22, 2009 at 9:54 PM, Bryant Luk <[email protected]> wrote: > >> 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 >> > -- - Bryant Luk
