You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by "Mike Rheinheimer (JIRA)" <ji...@apache.org> on 2010/02/20 19:38:28 UTC
[jira] Created: (WINK-257) allow Application subclass to control
provider priority
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
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-257) allow Application subclass to control
provider priority
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated WINK-257:
----------------------------------
Attachment: WINK-257.patch
Patch includes update to wink-jackson-provider's pom.xml to upgrade from Jackson 1.2 to 1.4, which required a few test changes in the wink-jackson-provider module.
> 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. 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-257) allow Application subclass to control
provider priority
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (WINK-257) allow Application subclass to control
provider priority
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer resolved WINK-257.
-----------------------------------
Resolution: Fixed
Assignee: Mike Rheinheimer
Committed in SVN 918091.
> 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
> Assignee: 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.
[jira] Commented: (WINK-257) allow Application subclass to control
provider priority
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840227#action_12840227 ]
Hudson commented on WINK-257:
-----------------------------
Integrated in Wink-Trunk-JDK1.5 #282 (See [http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5/282/])
: allow Application subclass control over provider priority
> 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
> Assignee: 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.
[jira] Closed: (WINK-257) allow Application subclass to control
provider priority
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer closed WINK-257.
---------------------------------
> 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
> Assignee: 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.
[jira] Commented: (WINK-257) allow Application subclass to control
provider priority
Posted by "Bryant Luk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836447#action_12836447 ]
Bryant Luk commented on WINK-257:
---------------------------------
I think this change makes a lot of sense. This makes some nice side effects while preserving the order of providers. Take the internal File Provider (http://svn.apache.org/repos/asf/incubator/wink/trunk/wink-common/src/main/java/org/apache/wink/common/internal/providers/entity/FileProvider.java). If a user creates an instance in the Application.getSingletons() method to customize the directory to store files to, then this allows an easier way to do so. Currently, the user has to either create their own java.io.File provider or subclass the internal provider (because if they added an instance of the existing FileProvider directly, it would get ignored as it was already read in wink-providers).
> 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.