Proxy for a Spring-managed Struts Action that's defined in
ContextLoaderPlugIn's WebApplicationContext.
The proxy is defined in the Struts config file, specifying this
class as action class. It will delegate to a Struts Action bean
in the ContextLoaderPlugIn context.
The name of the Action bean in the WebApplicationContext will be
determined from the mapping path and module prefix. This can be
customized by overriding the determineActionBeanName method.
Example:
mapping path "/login" -> bean name "/login"
mapping path "/login", module prefix "/mymodule" ->
bean name "/mymodule/login"
A corresponding bean definition in the ContextLoaderPlugin
context looks as follows, being able to fully leverage
Spring's configuration facilities:
Note that you can use a single ContextLoaderPlugIn for all Struts modules.
That context can in turn be loaded from multiple XML files, for example split
according to Struts modules. Alternatively, define one ContextLoaderPlugIn per
Struts module, specifying appropriate "contextConfigLocation" parameters.
In both cases, the Spring bean name has to include the module prefix.
If you want to avoid having to specify DelegatingActionProxy as Action
type in your struts-config, for example to be able to generate your
Struts config file with XDoclet, consider
DelegatingRequestProcessor .
The latter's disadvantage is that it might conflict with the need
for a different RequestProcessor subclass.
The default implementation delegates to the DelegatingActionUtils
class as fas as possible, to reuse as much code as possible with
DelegatingRequestProcessor and DelegatingTilesRequestProcessor.
Note: The idea of delegating to Spring-managed Struts Actions originated in
Don Brown's Spring Struts Plugin.
ContextLoaderPlugIn and DelegatingActionProxy constitute a clean-room
implementation of the same idea, essentially superseding the original plugin.
Many thanks to Don Brown and Matt Raible for the original work and for the
agreement to reimplement the idea in Spring proper!
The proxy is defined in the Struts config file, specifying this class as action class. It will delegate to a Struts Action bean in the ContextLoaderPlugIn context.
The name of the Action bean in the WebApplicationContext will be determined from the mapping path and module prefix. This can be customized by overriding thedetermineActionBeanNamemethod.Example:
A corresponding bean definition in the ContextLoaderPlugin context looks as follows, being able to fully leverage Spring's configuration facilities:
Note that you can use a single ContextLoaderPlugIn for all Struts modules. That context can in turn be loaded from multiple XML files, for example split according to Struts modules. Alternatively, define one ContextLoaderPlugIn per Struts module, specifying appropriate "contextConfigLocation" parameters. In both cases, the Spring bean name has to include the module prefix.If you want to avoid having to specify DelegatingActionProxy as Action type in your struts-config, for example to be able to generate your Struts config file with XDoclet, consider DelegatingRequestProcessor . The latter's disadvantage is that it might conflict with the need for a different RequestProcessor subclass.
The default implementation delegates to the DelegatingActionUtils class as fas as possible, to reuse as much code as possible with DelegatingRequestProcessor and DelegatingTilesRequestProcessor.
Note: The idea of delegating to Spring-managed Struts Actions originated in Don Brown's Spring Struts Plugin. ContextLoaderPlugIn and DelegatingActionProxy constitute a clean-room implementation of the same idea, essentially superseding the original plugin. Many thanks to Don Brown and Matt Raible for the original work and for the agreement to reimplement the idea in Spring proper!