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
