| Subclass of Struts's default
RequestProcessor that looks up
Spring-managed Struts
Action Actions defined in
ContextLoaderPlugIn ContextLoaderPlugIn's
WebApplicationContext (or, as a fallback, in the root 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
DelegatingRequestProcessor.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:
<bean name="/login" class="myapp.MyAction">
<property name="...">...</property>
</bean>
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 is 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 the Struts Action type in
your struts-config file.
The default implementation delegates to the
DelegatingActionUtils class as much 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.
author:
Juergen Hoeller
since:
1.0.2
See Also: DelegatingRequestProcessor.determineActionBeanName
See Also: DelegatingTilesRequestProcessor
See Also: DelegatingActionProxy
See Also: DelegatingActionUtils
See Also: ContextLoaderPlugIn |