Skip to end of metadata
Go to start of metadata

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.

Configuring Stripes in your web.xml
<?xml version="1.0" encoding="UTF-8"?> 

<web-app xmlns="" 

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

		<display-name>Stripes Filter</display-name> 






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 runtime 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:





The fully qualified name of a class that implements Configuration


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

Using a different configuration
	<display-name>Stripes Filter</display-name> 


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:





The FQN of a class that implements ActionResolver



The FQN of a class that implements ActionBeanPropertyBinder



The FQN of a class that implements ActionBeanContextFactory



Interceptors that are loaded by Stripes, regardless to Interceptor.Class param. Those are loaded before Interceptors' one, if any

net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor, net.sourceforge.stripes.controller.HttpCacheInterceptor


The FQN of a class that implements ExceptionHandler



A list of packages that will be searched for Stripes extensions. Examples of extensions include interceptors, formatters, type converters, exception handlers, object post-processors (release 1.6. and later) and custom implementations of ActionResolver, ActionBeanContext, ActionBeanContextFactory, FormatterFactory, LocalePicker, LocalizationBundleFactory, MultipartWrapperFactory, PopulationStrategy, TagErrorRendererFactory, TypeConverterFactory and ObjectFactory (release 1.6 and later). Most applications can simply set the Extension.Packages, ActionResolver.Packages and Stripes.EncryptionKey parameters and be done.

No default value. If this property is not set then extension autodiscovery will be disabled.


The FQN of a class that implements FormatterFactory



The comma-separated list of fully qualified class names of Interceptor classes to use. The list may contain additional whitespace. Entries higher up the list will be invoked before entries lower down.

No default values. See CoreInterceptor for others Interceptors loaded by Stripes.


The FQN of a class that implements LocalePicker



The FQN of a class that implements LocalizationBundleFactory



The FQN of a class that implements MultipartWrapperFactory



The FQN of a class that implements PopulationStrategy



The FQN of a class that implements TagErrorRendererFactory



The FQN of a class that implements TypeConverterFactory



A boolean flag that turns debug mode off or on. This should only be set to true during development. Currently, debug mode only turns off encryption, allowing a developer to read values that would otherwise be encrypted before being written to the client.
WARNING: Do not turn on debug mode in a production server. When encryption is disabled, you risk exposing resources that are normally protected, such as those under /WEB-INF.



A (preferably very long, very random) string that is used as the encryption key when Stripes encrypts values before sending them to the client. If no encryption key is specified, then a random one is generated each time the application is initialized. When a random key is used, encrypted values do not survive across application reloads.

No default value. A random key is generated each time the application is initialized.


The type of HTML tags Stripes should generate. Options are html or xhtml



The comma-separated list of fully qualified class names of VFS implementations to use in addition to the built-in implementations shipped with Stripes. The list may contain additional whitespace. The implementations are tried in the order they are specified and before any built-ins.

No default value.

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 a common package.





A comma-separated list of package roots where your ActionBean classes are. Stripes auto-discovers your ActionBeans at runtime 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.

No defaut value. This parameter is required.

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.





The FQN of a class which extends ActionBeanContext


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.





A comma separated list of package roots where your ExceptionHandlers are. Stripes will also search the packages specified in Extension.Packages for ExceptionHandlers so this parameter usually is not necessary.

Empty - search the packages specified by Extension.Packages.

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.





A comma separated list of locales that the system supports. Each locale can be one to three segments long (e.g. en or en-us or en-us-mac). Either hypens or underscores can be used to separate the segments. In addition each locale can optinally include a character encoding to use with that locale. The character encoding is specified by appending :encoding to the locale, e.g. en_US:UTF-8

The system default locale as returned by Locale.getDefault().

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.





The name of a resource bundle. This may by any kind of resource bundle, but will typically be a property resource bundle, in which case the resource files should be available in the classpath.

StripesResources which will lead to a file called being looked for on the classpath, and potentially locale specific properties files as well.


The name of a resource bundle. This may by any kind of resource bundle, but will typically be a property resource bundle, in which case the resource files should be available in the classpath.

StripesResources which will lead to a file called being looked for on the classpath, and potentially locale specific properties files as well.

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.





The maximum HTTP Post size, in bytes, that will be accepted by the server. Note that this is not the maximum file size, but the combined size of all files in a single upload plus any other form fields and headers. In practical terms, this should be slightly larger (say 20-50k) than the maximum file size you want to handle, in order to allow for a reasonable amount of other data to come in the same request. The number is assumed to be in bytes unless a k/kb/m/mb/g/gb suffix is applied.

10 Megabytes.


The fully qualified name of the class, implementing MultipartWrapper.


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:





When true Stripes will call the validate() method regardless of whether earlier validation phases produced validation errors or not. (Introduced in Stripes 1.2)



  • No labels

1 Comment

  1. Hi,

    Could you please elaborate on multiple stripes applications in a war file.

    I am looking for something like as below:

    App 1 --> Customers management

    App 2 --> Order Management

    App 3 --> Product Management

    App 4 --> Shipping Management

    App 5 --> Authentication/Authorization

    Is it possible by using Stripes multiple apps mechanism to deploy all of the above apps individually in their own .war files; at the same time allow them communicate with each other without resorting to SOAP/REST or any other integration patterns. I mean, communicate exclusively within Stripes boundaries.

    For example, when an ORDER is received from a CUSTOMER for a PRODUCT that needs to be SHIPPED to an address. Apps/modules 1 to 4 will speak to 5 obviously, at the same time Order will check Customer module to check if the customer exists in db. Similarly,

    Is there anything possible similar to Django(Python) installable apps or Padrino(Ruby) mountable apps/sub apps in Stripes ?

    Any code examples are much appreciated.

    Many Thanks.