Package org.apache.struts2.dispatcher

This package contains a reimagining of the traditional Struts filter dispatchers.

See: Description

Interface Summary

Interface	Description
DispatcherErrorHandler	Implementation of this interface is used to handle internal errors or missing resources.
DispatcherListener	A interface to tag those that want to execute code on the init and destory of a Dispatcher.
HostConfig	Abstraction for host configuration information such as init params or the servlet context.
Parameter
StaticContentLoader	Interface for loading static resources, based on a path.

Class Summary

Class	Description
ApplicationMap	A simple implementation of the Map interface to handle a collection of attributes and init parameters in a ServletContext object.
DefaultActionSupport	A simple action support class that sets properties to be able to serve
DefaultDispatcherErrorHandler	Default implementation of DispatcherErrorHandler which sends Error Report in devMode or HttpServletResponse.sendError(int, java.lang.String) otherwise.
DefaultStaticContentLoader	Default implementation to server static content
Dispatcher	A utility class the actual dispatcher delegates most of its tasks to.
Dispatcher.Locator	Provide an accessor class for static XWork utility.
ExecuteOperations	Contains execution operations for filters
HttpParameters
HttpParameters.Builder
InitOperations	Contains initialization operations
LocalizedMessage
MockDispatcher
Parameter.Empty
Parameter.File
Parameter.Request
PrepareOperations	Contains preparation operations for a request before execution
RequestMap	A simple implementation of the Map interface to handle a collection of request attributes.
SessionMap<K,V>	A simple implementation of the Map interface to handle a collection of HTTP session attributes.
StrutsRequestWrapper	All Struts requests are wrapped with this class, which provides simple JSTL accessibility.

Package org.apache.struts2.dispatcher Description

This package contains a reimagining of the traditional Struts filter dispatchers. Each specific deployment has their own filters to prevent confusion. In addition, the operations have been explicitly pulled into *Operations objects that try to document through method naming what is happening at every step. Here are a few common use cases and how you would manage the Struts deployment:

Simple Dispatcher

 <filter>
     <filter-name>struts2</filter-name>
     <filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter</filter-class>
 </filter>

 <filter-mapping>
     <filter-name>struts2</filter-name>
     <url-pattern>/*</url-pattern>
 </filter-mapping>
 

Deployment with Sitemesh

 <filter>
     <filter-name>struts2-prepare</filter-name>
     <filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareFilter</filter-class>
 </filter>
 <filter>
     <filter-name>sitemesh</filter-name>
     <filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>
 </filter>
 <filter>
     <filter-name>struts2-execute</filter-name>
     <filter-class>org.apache.struts2.dispatcher.filter.StrutsExecuteFilter</filter-class>
 </filter>

 <filter-mapping>
     <filter-name>struts2-prepare</filter-name>
     <url-pattern>/*</url-pattern>
 </filter-mapping>
 <filter-mapping>
     <filter-name>sitemesh</filter-name>
     <url-pattern>/*</url-pattern>
 </filter-mapping>
 <filter-mapping>
     <filter-name>struts2-execute</filter-name>
     <url-pattern>/*</url-pattern>
 </filter-mapping>