I think this change (while seemingly a lot for moving a single line up 2 lines ) is good. For users that always expect their providers/applications to always be loaded first, this will ensure that happens.
On Mon, Feb 22, 2010 at 10:55 PM, Mike Rheinheimer <[email protected]> wrote: > Hi, > > I wanted to call attention to WINK-257 > (https://issues.ahttps://issues.apache.org/jira/browse/WINK-257pache.org/jira/browse/WINK-257) > since it proposes a fundamental change to the order of provider > loading. > > Currently, the order of provider loading is from wink-providers file, > all wink-application files, getSingletons, then getClasses. Consider > the wink-providers and wink-application files to be a group, and > getSingletons and getClasses to be a group. The latter group always > takes precedence over the former, UNLESS a provider of the same class > type is listed in both, in which case the latter loaded is silently > ignored. Within a group, the latter of multiple providers that > support the same MediaType takes precedence. Perhaps an example would > be helpful. :) > > Let's say with have the following lists. Assume we have A.class, > B.class, C.class, and D.class, all of which support the same > MediaType. > > wink-providers lists: > A.class > wink-application lists: > A.class > B.class > getSingletons > C.class > B.class > getClasses > D.class > > The Application.getSingletons has listed B.class after C.class in the > hopes that B, which has some programmatic customizations > (FileProvider, perhaps?) would take precedence over C. However, > consider the load order, which follows the order listed above: > > A.class (from wink-providers) > A.class (from wink-application is silently ignored) > B.class (from wink-application) > C.class (from getSingletons) > B.class (from getSingletons is silently ignored, which is not what > the developer wants or expects) > D.class (from getClasses) > > So the final priority order is D, C, B, A. Remember, Application > developer wanted B ahead of C, but as you see, it is not. > > The proposed change in WINK-257 is to load the getSingletons, > getClasses group ahead of the wink-providers, wink-application group > so as to give full control to the Application subclass developer. > > Revisiting the example, we have: > > getSingletons > C.class > B.class > getClasses > D.class > wink-providers lists: > A.class > wink-application lists: > A.class > B.class > > Now the load order is as such: > > C.class (from getSingletons) > B.class (from getSingletons) > D.class (from getClasses) > A.class (from wink-providers) > A.class (from wink-application is silently ignored) > B.class (from wink-application is silently ignored) > > So the final priority order is D, B, C, A (remember the group > getSingletons + getClasses takes priority over the wink-providers, > wink-application group). In this priority list, B is ahead of C, > which is exactly what the Application developer wanted. > > Hope that makes sense. The change in WINK-257 is a one-line change to > production code. I've put in quite a few new tests, and tested it > thoroughly. Please let me know if there are any objections to this > change, or any changes or additional testing you'd like to see. > > Thanks.. > mike >
