fundamental change to order of Provider loading

[Mike Rheinheimer <ro...@ohmyhead.com>]

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