Subclass of Struts' default RequestProcessor that looks up Spring-managed
Struts Actions defined in ContextLoaderPlugIn's WebApplicationContext.
In the Struts config file, you can either specify the original Action class
(as when generated by XDoclet), or no Action class at all. In any case, Struts
will delegate to an Action bean in the ContextLoaderPlugIn context.
<action path="/login" type="myapp.MyAction"/>
or
<action path="/login"/>
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 also need the Tiles setup functionality of the original
TilesRequestProcessor, use DelegatingTilesRequestProcessor. As there's just
a single central class to customize in Struts, we have to provide another
subclass here, covering both the Tiles and the Spring delegation aspect.
If this RequestProcessor conflicts with the need for a different
RequestProcessor subclass (other than TilesRequestProcessor), consider
using DelegatingActionProxy as Struts
Action type in your struts-config.
The default implementation delegates to the DelegatingActionUtils
class as fas as possible, to reuse as much code as possible despite
the need to provide two RequestProcessor subclasses. If you need to
subclass yet another RequestProcessor, take this class as a template,
delegating to DelegatingActionUtils just like it.
In the Struts config file, you can either specify the original Action class (as when generated by XDoclet), or no Action class at all. In any case, Struts will delegate to an Action bean in the ContextLoaderPlugIn context.
or 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 also need the Tiles setup functionality of the original TilesRequestProcessor, use DelegatingTilesRequestProcessor. As there's just a single central class to customize in Struts, we have to provide another subclass here, covering both the Tiles and the Spring delegation aspect.
If this RequestProcessor conflicts with the need for a different RequestProcessor subclass (other than TilesRequestProcessor), consider using DelegatingActionProxy as Struts Action type in your struts-config.
The default implementation delegates to the DelegatingActionUtils class as fas as possible, to reuse as much code as possible despite the need to provide two RequestProcessor subclasses. If you need to subclass yet another RequestProcessor, take this class as a template, delegating to DelegatingActionUtils just like it.