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