You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Brian Pontarelli (JIRA)" <ji...@apache.org> on 2007/09/18 16:40:36 UTC
[jira] Created: (WW-2192) Rework ConfigurationProvider loading
Rework ConfigurationProvider loading
------------------------------------
Key: WW-2192
URL: https://issues.apache.org/struts/browse/WW-2192
Project: Struts 2
Issue Type: Improvement
Components: Configuration
Affects Versions: 2.1.0
Reporter: Brian Pontarelli
Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2192) Rework ConfigurationProvider loading
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Don Brown updated WW-2192:
--------------------------
Affects Version/s: (was: 2.1.0)
2.0.10
Fix Version/s: 2.1.0
> Rework ConfigurationProvider loading
> ------------------------------------
>
> Key: WW-2192
> URL: https://issues.apache.org/struts/browse/WW-2192
> Project: Struts 2
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.0.10
> Reporter: Brian Pontarelli
> Fix For: 2.1.0
>
>
> Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
> This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
> The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
> Also, because a Struts application could now handle many different types of configuration much more transparently, the ConfigurationProvider interface should provide some new life-cycle methods that allow ConfigurationProviders to do pre and post processing. An example of how this would be necessary is for handling index actions. A ConfigurationProvider might need to determine if an action exists in a particular namespace prior to setting up additional results and new actions. Therefore, it would be nice to have the ability to load all the configuration and then post process the configuration so that all of the namespaces, actions and results are setup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2192) Rework ConfigurationProvider loading
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42332 ]
Don Brown commented on WW-2192:
-------------------------------
I added it to the list of plugin extensions (by modifying the javadocs in BeanSelectionProvider) but that hadn't triggered a re-export of the page. Just did a trivial change so it would re-export. If you want to create additional docs, feel free. The more the better :)
> Rework ConfigurationProvider loading
> ------------------------------------
>
> Key: WW-2192
> URL: https://issues.apache.org/struts/browse/WW-2192
> Project: Struts 2
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.0.10
> Reporter: Brian Pontarelli
> Assignee: Don Brown
> Fix For: 2.1.0
>
>
> Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
> This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
> The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
> Also, because a Struts application could now handle many different types of configuration much more transparently, the ConfigurationProvider interface should provide some new life-cycle methods that allow ConfigurationProviders to do pre and post processing. An example of how this would be necessary is for handling index actions. A ConfigurationProvider might need to determine if an action exists in a particular namespace prior to setting up additional results and new actions. Therefore, it would be nice to have the ability to load all the configuration and then post process the configuration so that all of the namespaces, actions and results are setup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2192) Rework ConfigurationProvider loading
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42326 ]
Don Brown commented on WW-2192:
-------------------------------
Let's put the request for pre/post package loading in another ticket. I implemented pluggable package loading in xwork in such a way that backwards-compatibility was preserved. It really isn't possible to make container bean and constant loading pluggable due to how it works, but package loading was pretty straightforward.
> Rework ConfigurationProvider loading
> ------------------------------------
>
> Key: WW-2192
> URL: https://issues.apache.org/struts/browse/WW-2192
> Project: Struts 2
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.0.10
> Reporter: Brian Pontarelli
> Assignee: Don Brown
> Fix For: 2.1.0
>
>
> Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
> This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
> The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
> Also, because a Struts application could now handle many different types of configuration much more transparently, the ConfigurationProvider interface should provide some new life-cycle methods that allow ConfigurationProviders to do pre and post processing. An example of how this would be necessary is for handling index actions. A ConfigurationProvider might need to determine if an action exists in a particular namespace prior to setting up additional results and new actions. Therefore, it would be nice to have the ability to load all the configuration and then post process the configuration so that all of the namespaces, actions and results are setup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2192) Rework ConfigurationProvider loading
Posted by "Brian Pontarelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Pontarelli updated WW-2192:
---------------------------------
Description:
Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
Also, because a Struts application could now handle many different types of configuration much more transparently, the ConfigurationProvider interface should provide some new life-cycle methods that allow ConfigurationProviders to do pre and post processing. An example of how this would be necessary is for handling index actions. A ConfigurationProvider might need to determine if an action exists in a particular namespace prior to setting up additional results and new actions. Therefore, it would be nice to have the ability to load all the configuration and then post process the configuration so that all of the namespaces, actions and results are setup.
was:
Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
> Rework ConfigurationProvider loading
> ------------------------------------
>
> Key: WW-2192
> URL: https://issues.apache.org/struts/browse/WW-2192
> Project: Struts 2
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.1.0
> Reporter: Brian Pontarelli
>
> Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
> This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
> The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
> Also, because a Struts application could now handle many different types of configuration much more transparently, the ConfigurationProvider interface should provide some new life-cycle methods that allow ConfigurationProviders to do pre and post processing. An example of how this would be necessary is for handling index actions. A ConfigurationProvider might need to determine if an action exists in a particular namespace prior to setting up additional results and new actions. Therefore, it would be nice to have the ability to load all the configuration and then post process the configuration so that all of the namespaces, actions and results are setup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WW-2192) Rework ConfigurationProvider loading
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Don Brown resolved WW-2192.
---------------------------
Resolution: Fixed
Assignee: Don Brown
http://jira.opensymphony.com/browse/XW-575
> Rework ConfigurationProvider loading
> ------------------------------------
>
> Key: WW-2192
> URL: https://issues.apache.org/struts/browse/WW-2192
> Project: Struts 2
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.0.10
> Reporter: Brian Pontarelli
> Assignee: Don Brown
> Fix For: 2.1.0
>
>
> Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
> This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
> The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
> Also, because a Struts application could now handle many different types of configuration much more transparently, the ConfigurationProvider interface should provide some new life-cycle methods that allow ConfigurationProviders to do pre and post processing. An example of how this would be necessary is for handling index actions. A ConfigurationProvider might need to determine if an action exists in a particular namespace prior to setting up additional results and new actions. Therefore, it would be nice to have the ability to load all the configuration and then post process the configuration so that all of the namespaces, actions and results are setup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2192) Rework ConfigurationProvider loading
Posted by "Brian Pontarelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42328 ]
Brian Pontarelli commented on WW-2192:
--------------------------------------
Let's also make sure to include this in the plug-in documentation, because it is really vital to allowing plugins the opportunity to provide configuration. Should we open another issue just to be certain, or re-open this to include the documentation as well?
> Rework ConfigurationProvider loading
> ------------------------------------
>
> Key: WW-2192
> URL: https://issues.apache.org/struts/browse/WW-2192
> Project: Struts 2
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.0.10
> Reporter: Brian Pontarelli
> Assignee: Don Brown
> Fix For: 2.1.0
>
>
> Currently, the only mechanism for loading custom ConfigurationProviders is to add them to web.xml (roughly speaking), which makes it difficult for plugins to supply additional ConfigurationProviders without requiring the user of the plugin to modify their web.xml file(s).
> This feature would allow plugins to supply additional ConfigurationProviders within the struts-plugin.xml file as standard bean definitions or as a new configuration definition.
> The Container injection framework would probably need to first load all the ConfigurationProviders only and hand those to the Dispatcher so that it can be bootstrapped. Next, the Container would load the rest of the beans and values as normal. This would require a change in the initialization life-cycle of the Struts framework and possibly changes the the struts-plugin.xml definition (DTD or schema).
> Also, because a Struts application could now handle many different types of configuration much more transparently, the ConfigurationProvider interface should provide some new life-cycle methods that allow ConfigurationProviders to do pre and post processing. An example of how this would be necessary is for handling index actions. A ConfigurationProvider might need to determine if an action exists in a particular namespace prior to setting up additional results and new actions. Therefore, it would be nice to have the ability to load all the configuration and then post process the configuration so that all of the namespaces, actions and results are setup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.