|Apache Struts 2 Documentation > Home > Guides > Core Developers Guide > Configuration Files > web.xml|
The web.xml web application descriptor file represents the core of the Java web application, so it is appropriate that it is also part of the core of the Struts framework. In the web.xml file, Struts defines its FilterDispatcher, the Servlet Filter class that initializes the Struts framework and handles all requests. This filter can contain initialization parameters that affect what, if any, additional configuration files are loaded and how the framework should behave.
In addition to the FilterDispatcher, Struts also provides an ActionContextCleanUp class that handles special cleanup tasks when other filters, such as those used by Sitemesh, need access to an initialized Struts framework.
Configuring web.xml for the framework is a matter of adding a filter and filter-mapping.
|Changed Filter Structure in Struts >= 2.1.3|
To split up the the dispatcher phases, FilterDispatcher is deprecated since Struts 2.1.3. If working with older versions, you need to use
See SiteMesh Plugin for an example on when to use seperate Filters for prepare and execution phase
|Why the Filter is mapped with /* and how to configure explicit exclusions (since 2.1.7)|
If we change the filter mapping to something else, for example /*.html, we must take this in to account and extract the content that would normally be served from the Struts 2 jar files, or some other solution.
Since Struts 2.1.7, you are able to provide a comma seperated list of patterns for which when matching against the
Typically, configuring a taglib is neither required nor recommended. The taglib is included in struts-core.jar, and the container will discover it automatically.
If, for some reason, a taglib configuration is needed within web.xml, extract the TLD file from the struts-core.jar META-INF folder, and add a taglib element to the web.xml.
If there is a need to support an App Server's specific file system (eg. VFS in JBoss), you can implement your own version of FileManager. But it must be registered at "the beginning" to support bootstrap of the whole framework.
To register your own FileManger you can do it with <init-param/> as below:
You can as well register your own FileManagerFactory with <init-param/>, see example:
Take a look on default implementations - DefaultFileManager.java and DefaultFileManagerFactory.java to understand how and why.