| java.lang.Object
 com.opensymphony.webwork.dispatcher.FilterDispatcher
All known Subclasses: com.opensymphony.webwork.pico.PicoFilterDispatcher, com.opensymphony.webwork.dispatcher.FilterDispatcherCompatWeblogic61,
| FilterDispatcher | | public class FilterDispatcher implements Filter,WebWorkStatics(Code) | | Master filter for WebWork that handles four distinct responsibilities:
- Executing actions
- Cleaning up the
ActionContext (see note)
- Serving static content
- Kicking off XWork's IoC for the request lifecycle
IMPORTANT: this filter must be mapped to all requests. Unless you know exactly what you are doing, always
map to this URL pattern: /*
Executing actions
This filter executes actions by consulting the
ActionMapper and determining if the requested URL should
invoke an action. If the mapper indicates it should, the rest of the filter chain is stopped and the action is
invoked. This is important, as it means that filters like the SiteMesh filter must be placed before this
filter or they will not be able to decorate the output of actions.
Cleaning up the
ActionContext
This filter will also automatically clean up the
ActionContext for you, ensuring that no memory leaks
take place. However, this can sometimes cause problems integrating with other products like SiteMesh. See
ActionContextCleanUp for more information on how to deal with this.
Serving static content
This filter also serves common static content needed when using various parts of WebWork, such as JavaScript
files, CSS files, etc. It works by looking for requests to /webwork/*, and then mapping the value after "/webwork/"
to common packages in WebWork and, optionally, in your class path. By default, the following packages are
automatically searched:
- com.opensymphony.webwork.static
- template
This means that you can simply request /webwork/xhtml/styles.css and the XHTML UI theme's default stylesheet
will be returned. Likewise, many of the AJAX UI components require various JavaScript files, which are found in the
com.opensymphony.webwork.static package. If you wish to add additional packages to be searched, you can add a comma
separated (space, tab and new line will do as well) list in the filter init parameter named "packages". Be
careful, however, to expose any packages that may have sensitive information, such as properties file with
database access credentials.
Kicking off XWork's IoC for the request lifecycle
This filter also kicks off the XWork IoC request scope, provided that you are using XWork's IoC. All you have to
do to get started with XWork's IoC is add a components.xml file to WEB-INF/classes and properly set up the
com.opensymphony.webwork.lifecycle.LifecycleListener in web.xml. See the IoC docs for more information.
author:
Patrick Lightbody
author:
tm_jee
See Also: com.opensymphony.webwork.lifecycle.LifecycleListener
See Also: ActionMapper
See Also: ActionContextCleanUp
since:
2.2 |
| checkUrl | | protected boolean checkUrl(URL url, String rawResourcePath)(Code) | | handle .. chars here and other URL hacks
|
| createComponentManager | | protected DefaultComponentManager createComponentManager()(Code) | | Returns a new DefaultComponentManager instance. This method is useful for developers wishing to subclass
this class and provide a different implementation of DefaultComponentManager.
a new DefaultComponentManager instance. |
| destroy | | public void destroy()(Code) | | |
| getServletContext | | protected ServletContext getServletContext(HttpSession session)(Code) | | Servlet 2.3 specifies that the servlet context can be retrieved from the session. Unfortunately, some versions of
WebLogic can only retrieve the servlet context from the filter config. Hence, this method enables subclasses to
retrieve the servlet context from other sources.
Parameters:
session - the HTTP session where, in Servlet 2.3, the servlet context can be retrieved the servlet context. |
|
|