Stripes requires minimal configuration to get up and running, and zero configuration per ActionBean or page. That said, it is possible to change some of Stripes' behaviour using configuration. The way this is handled is that a Configuration object is responsible for supplying instances of various ConfigurableComponents to parts of Stripes that need them.

When you fire up Stripes without any additional Configuration, Stripes will use an instance of RuntimeConfiguration that extends the DefaultConfiguration and is capable of overriding the defaults if configured to do so. The following sections will walk through how to configure the components of Stripes that are used by default, and how to override those components with custom components developed for your project. Note that while you may supply alternative implementations for any ConfigurableComponent, not all the default implementations have configuration properties of their own.

Initial Configuration

To get up and running all you need to do is configure the Stripes dispatcher servlet, and the Stripes filter in your web.xml. The following shows an example configuration.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
         http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
         version="2.4">

    <description>A description of your web application</description>
    <display-name>Your web application's name</display-name>

	<filter>
		<display-name>Stripes Filter</display-name>
		<filter-name>StripesFilter</filter-name>
		<filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class>
		<init-param>
			<param-name>ActionResolver.Packages</param-name>
			<param-value>my.action.bean.pkg</param-value>
		</init-param>
	</filter>

	<filter-mapping>
		<filter-name>StripesFilter</filter-name>
		<url-pattern>*.jsp</url-pattern>
		<dispatcher>REQUEST</dispatcher>
	</filter-mapping>

	<filter-mapping>
		<filter-name>StripesFilter</filter-name>
		<servlet-name>StripesDispatcher</servlet-name>
		<dispatcher>REQUEST</dispatcher>
	</filter-mapping>

	<servlet>
		<servlet-name>StripesDispatcher</servlet-name>
		<servlet-class>net.sourceforge.stripes.controller.DispatcherServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<servlet-mapping>
		<servlet-name>StripesDispatcher</servlet-name>
		<url-pattern>*.action</url-pattern>
	</servlet-mapping>
</web-app>

Note that the last piece, configuring a servlet mapping for *.action can be replaced or augmented with any pattern you choose.

The ActionResolver.Packages parameter The ActionResolver.Packages Stripes Filter init-param is required. Indicate one or more package roots (without .*, subpackages are automatically included) where your ActionBean classes are. Stripes auto-discovers your ActionBeans at deployment time by scanning those packages and their subpackages. This saves you from having to enumerate all your ActionBeans somewhere and maintaining that when you add, change, or remove ActionBeans.

Supplying Additional Configuration

In order to keep things simple, there are no external configuration files with Stripes. All of the ConfigurableComponents in Stripes use the same mechanism to find configuration properties. When a property is looked for, it is first looked for as an initialization parameter to the Stripes Filter. If a value is not found there, the property is looked for as an initialization parameter for the Web Application within which Stripes is running. If a value cannot be found there, it is looked for in the Java System Properties.

It is expected that in 99% of the cases all configuration will be done using initialization parameters for the Stripes Filter, since in most cases you will want to have a single Stripes application per web application. The other two levels become more useful if you have multiple Stripes applications and want to share configuration information across them, or want to be able to supply different values at the command line for different environments.

Configuration Configuration

As mentioned above, Stripes uses a Configuration object to drive it's runtime configuration. Two implemenations ship with Stripes. The DefaultConfiguration does not take any parameters itself, but initializes the default implementation for each component, and the components themselves may take parameters. The RuntimeConfiguration uses properties to determine at runtime which component implementations to instantiate. Despite the names, unless you configure it otherwise, Stripes will use a RuntimeConfiguration (DefaultConfiguration is named so because it provides the default configuration information, not because it is the default).

To specify a custom Configuration implementation use:

For example, to switch to using your own Configuration, you might make the following change to your web.xml:

<filter>
    <display-name>Stripes Filter</display-name>
    <filter-name>StripesFilter</filter-name>
    <filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class>
    <init-param>
        <param-name>Configuration.Class</param-name>
        <param-value>com.myco.CustomConfiguration</param-value>
    </init-param>
</filter>

RuntimeConfiguration Properties

The RuntimeConfiguration supports properties for specifying the implementation of each configured component. For more information on what each component is and what it does, click on the links for each of the interfaces. The supported properties are:

ActionResolver Properties

The properties in this section affect how the AnnotatedClassActionResolver and NameBasedActionResolver (the only ActionResolvers included with Stripes) function. The ActionResolver is responsible for finding implementations of ActionBean at runtime. The included ActionResolvers do this by searching your web application classpath for all classes that implement ActionBean. While an exhaustive search is guaranteed to find everything, it can be quite slow. In reality your ActionBeans probably all get compiled and placed into the same location in your classpath, e.g. under WEB-INF/classes or WEB-INF/lib/my-project.jar.

ActionBeanContextFactory Properties

The DefaultActionBeanContextFactory allows you to provide an application specific subclass of ActionBeanContext to be used within your application. This is useful as it allows you to isolate yourself from any interaction with HttpServletRequest and HttpServletResponse in your ActionBeans by providing type safe getters and setters for any attributes you need to access in session etc.

ExceptionHandler Properties

The DefaultExceptionHandler does not make use of any configuration properties. However, the DelegatingExceptionHandler also included in Stripes does. Like the ActionResolvers, it scans the classpath for classes (in this case AutoExceptionHandler classes), and can be configured to look in only specific places.

LocalePicker Properties

The LocalePicker is responsible for picking the Locale under which a request will be processed, and optionally a character encoding. In non-localized systems this is usually just the system locale and character encoding, but in localized systems a match needs to be performed between the list of Locales the user accepts and the list of Locales the server can provide. Properties in this section affect how the DefaultLocalePicker (the only LocalePicker included with Stripes) functions.

LocalizationBundleFactory Properties

The LocalizationBundleFactory is responsible for providing the rest of Stripes somewhere to lookup localized resources. At present Stripes defines two types of resources - error messages and field names - that may be looked up from the same or different bundles. The properties in this section affect how the DefaultLocalizationBundleFactory (the only LocalizationBundleFactory included with Stripes) operates.

File Upload / MultipartWrapperFactory Properties

Stripes provides an easy way to process file uploads using the HTTP multipart/form-data standard. This section documents properties that affect how the file upload process works.

Validation Properties

By default Stripes will not invoke the validation methods on ActionBeans if earlier validations (type conversion and annotation driven validation) resulted in validation errors. This behaviour can be overridden: