[
https://issues.apache.org/jira/browse/WINK-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Rheinheimer updated WINK-257:
----------------------------------
Description:
Currently, the only way to control priority order of providers that support the
same types is to edit the wink-providers file. Priority order cannot be
controlled in the Application subclass for a provider that is already listed in
wink-providers. For example, if a user adds the JacksonJsonProvider from the
Jackson project, it will take precedence over the already existing JsonProvider
from wink-providers. Because the JacksonJsonProvider.isReadable method is
"greedy", it will support all Object types and won't fall through to the
JsonProvider.
Customers may want to control this behavior programmatically. The providers
listed in the Application subclass should always take precedence over providers
listed in the wink-providers file, but in this case, a customer may want the
JsonProvider to take precedence over the JacksonJsonProvider.
I propose a change in the order of processing of the various providers list so
customers can control the provider precedence programmatically.
Current order of processing: wink-providers, wink-application, getSingletons,
getClasses
Proposed change: getSingletons, getClasses, wink-providers, wink-application
Once this change is made, a customer can list JacksonJsonProvider and
JsonProvider in that order in their LinkedHashSet returned from getSingletons
and have confidence that JsonProvider will be queried first.
That's just an example scenario. I think future customers will like having
control over the priority order of providers.
Please see patch. The change is a one-line change in
RestServlet.createRequestProcessor. I've had to adjust some tests, and added
several.
was:
Currently, the only way to control priority order of providers that support the
same types is to edit the wink-providers file. Priority order cannot be
controlled in the Application subclass for a provider that is already listed in
wink-providers. For example, if a user adds the JacksonJsonProvider from the
Jackson project, it will take precedence over the already existing JsonProvider
from wink-providers. Because the JacksonJsonProvider.isReadable method is
"greedy", it will support all Object types and won't fall through to the
JsonProvider.
Customers may want to control this behavior programmatically. Ideally, the
providers listed in the Application subclass should always take precedence over
providers listed in the wink-providers file.
I propose a change in the order of processing of the various providers list.
Current order of processing: wink-providers, wink-application, getSingletons,
getClasses
Proposed change: getSingletons, getClasses, wink-providers, wink-application
Once this change is made, a customer can list JacksonJsonProvider and
JsonProvider in that order in their LinkedHashSet returned from getSingletons
and have confidence that JsonProvider will be queried first.
That's just an example scenario. I think future customers will like having
control over the priority order of providers.
Please see patch. The change is a one-line change in
RestServlet.createRequestProcessor. I've had to adjust some tests, and added
several.
> allow Application subclass to control provider priority
> -------------------------------------------------------
>
> Key: WINK-257
> URL: https://issues.apache.org/jira/browse/WINK-257
> Project: Wink
> Issue Type: Improvement
> Components: Server
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-257.patch
>
>
> Currently, the only way to control priority order of providers that support
> the same types is to edit the wink-providers file. Priority order cannot be
> controlled in the Application subclass for a provider that is already listed
> in wink-providers. For example, if a user adds the JacksonJsonProvider from
> the Jackson project, it will take precedence over the already existing
> JsonProvider from wink-providers. Because the JacksonJsonProvider.isReadable
> method is "greedy", it will support all Object types and won't fall through
> to the JsonProvider.
> Customers may want to control this behavior programmatically. The providers
> listed in the Application subclass should always take precedence over
> providers listed in the wink-providers file, but in this case, a customer may
> want the JsonProvider to take precedence over the JacksonJsonProvider.
> I propose a change in the order of processing of the various providers list
> so customers can control the provider precedence programmatically.
> Current order of processing: wink-providers, wink-application,
> getSingletons, getClasses
> Proposed change: getSingletons, getClasses, wink-providers, wink-application
> Once this change is made, a customer can list JacksonJsonProvider and
> JsonProvider in that order in their LinkedHashSet returned from getSingletons
> and have confidence that JsonProvider will be queried first.
> That's just an example scenario. I think future customers will like having
> control over the priority order of providers.
> Please see patch. The change is a one-line change in
> RestServlet.createRequestProcessor. I've had to adjust some tests, and added
> several.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
