[jira] Updated: (WW-2192) Rework ConfigurationProvider loading

["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.