Stripes vs. Struts2

Here are some quick comparison points between Stripes and Struts2:

Actions

Stripes actions are defined by classes that implement the ActionBean interface, and are automatically loaded by being in one of the packages or subpackages of the packages listed in the ActionResolver.Packages initialization parameter.

Struts2 actions can be plain classes that have a public String execute() method, or classes that implement the Action interface. They must be declared in struts.xml, or automatically loaded with a mechanism copied from inspired by Stripes.

Event handlers

In Stripes, methods of the signature public Resolution methodName() in an action bean define event handlers. Using name= in submit buttons and event= in links with the name of the method targets that method when the action is triggered. Having more than one event handler, and more than one submit button in a form, is simply a matter of defining multiple event handlers and putting the corresponding name in the tag of the submit button.

Struts2 is geared towards having a single event handler method, execute(). You can have other event handler methods with arbitrary names, but you must configure a strategy in struts.xml for mapping a URL to a method name.

Struts2 makes it surprisingly difficult to have more than one submit button in a form. It's doable, but not in as straightforward a manner as in Stripes, as can be seen here.

Resolutions vs. Results

Stripes event handlers return implementations of the Resolution interface. Stripes comes with built-in implementations to forward or redirect a request, stream data, return a JavaScript object, or return an HTTP error code. It's very simple to implement the Resolution interface (it has just one method) to suit custom requirements.

Struts2's execute() methods return a String, which is a symbolic result which must then be mapped to something concrete, either in struts.xml or with an annotation. Arguably, returning a symbolic result and having to go off somewhere else to link the string to a result is an unnecessary burden on the developer. Tim discusses this topic in more detail here.

Custom Type Converters

With Stripes, writing a custom type converter involves implementing the TypeConverter<T> interface, where T is the target type. Then, you can use the type converter for every property of type T simply by putting the type converter in an Extension.Packages package. Alternatively, you can use the type converter for specific properties only by annotating the target property with @Validate(converter=YourTypeConverter.class).

With Struts2, you write a custom type converter by implementing the ognl.TypeConverter interface, usually by extending the StrutsTypeConverter class. Contrary to Stripes, the Struts2 interface is not generified, so your method will return an Object. To use the type converter for every property of type T, you add a line to xwork-conversion.properties with the property being the fully qualified name of T, and the value being the fully qualified class name of your type converter. For a specific property, you add the name of the property and the fully qualified class name of your type converter in ActionName-conversion.properties where ActionName is the class name of the action, and the file is in the same directory hierarchy as the package of the action class.

View Technology

The Stripes framework supports any view technology that supports JSP tag libraries. This means you can use JSP and Freemarker, as both can be implemented as a servlet mapping. JSP is available from J2EE, FreeMarker has to be configured as detailed in FreeMarker with Stripes. Using Velocity with Stripes is possible using the tools project VelocityView, but you will miss the taglib support. Velocity 1.5 doesn't support JSP taglibs – this is a feature on the 2.0 wishlist since 2006.

With Struts2, JSP is supported just like with Stripes. But Struts2 also has plugins to handle both Freemarker and Velocity, thus enabling it's functionality for both these view technologies. That being said, using Freemarker (or JSP) is somewhat more natural than Velocity. For example, for this markup:

 
<s:form action="Login"> 
<s:textfield name="username" label="Username"/> 
<s:submit value="Submit"/> 
</s:form> 

The Velocity equivalent is:

 
#sform ("action=Login") 
#stextfield ("name=username" "label=Username") 
#ssubmit ("value=Submit") 
#end 

Interceptors

Interceptors in Stripes are classes that implement the Interceptor interface and specify the lifecycle stage(s) to be intercepted with the @Intercepts annotation. Stripes will automatically load the class via the Extension.Packages mechanism. You can also configure interceptors in web.xml if the order in which interceptors are executed is important.

Struts2 interceptors also implement an Interceptor interface. You must then define the interceptor class in struts.xml, and define a new interceptor stack that uses the default stack and adds your interceptor. Finally, you have to configure which actions will use this new interceptor stack.