The proxy is defined in the Struts config file, specifying this
class as the action class. This class 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 would look as follows; notice that the Action is now
able to leverage fully 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 the Action type in your struts-config file (for example to
be able to generate your Struts config file with XDoclet) consider using the
DelegatingRequestProcessor .
The latter's disadvantage is that it might conflict with the need
for a different RequestProcessor subclass.
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!
Actionthat is defined in ContextLoaderPlugIn's WebApplicationContext .The proxy is defined in the Struts config file, specifying this class as the action class. This class will delegate to a Struts
The name of theActionbean in theContextLoaderPlugIncontext.Actionbean in theWebApplicationContextwill be determined from the mapping path and module prefix. This can be customized by overriding thedetermineActionBeanNamemethod.Example:
A corresponding bean definition in the
Note that you can use a singleContextLoaderPlugincontext would look as follows; notice that theActionis now able to leverage fully Spring's configuration facilities:ContextLoaderPlugInfor all Struts modules. That context can in turn be loaded from multiple XML files, for example split according to Struts modules. Alternatively, define oneContextLoaderPlugInper 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
DelegatingActionProxyas theActiontype in your struts-config file (for example to be able to generate your Struts config file with XDoclet) consider using the DelegatingRequestProcessor . The latter's disadvantage is that it might conflict with the need for a differentRequestProcessorsubclass.The default implementation delegates to the DelegatingActionUtils class as much as possible, to reuse as much code as possible with
DelegatingRequestProcessorand DelegatingTilesRequestProcessor .Note: The idea of delegating to Spring-managed Struts Actions originated in Don Brown's Spring Struts Plugin.
ContextLoaderPlugInandDelegatingActionProxyconstitute 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!