java.lang.ObjectSubclass of Struts's default RequestProcessor that looks up Spring-managed Struts Actions defined in ContextLoaderPlugIn's WebApplicationContext (or, as a fallback, in the rootorg.apache.struts.action.RequestProcessor
org.springframework.web.struts.DelegatingRequestProcessor
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:
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.
Juergen - Hoeller1.0.2 - | Method from org.springframework.web.struts.DelegatingRequestProcessor Summary: |
|---|
| determineActionBeanName, getDelegateAction, getWebApplicationContext, init, initWebApplicationContext, processActionCreate |
| Methods from java.lang.Object: |
|---|
| equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Method from org.springframework.web.struts.DelegatingRequestProcessor Detail: |
|---|
Action bean, to be looked up in
the WebApplicationContext.
The default implementation takes the mapping path and prepends the module prefix , if any. |
Action for the given mapping.
The default implementation determines a bean name from the
given |
WebApplicationContext that this processor
delegates to. |
|
ServletContext, falling back to the root
WebApplicationContext.
This context is supposed to contain the Struts |
|