Struts2 interceptors are a core mechanism for implementing cross-cutting concerns in web applications, leveraging aspect-oriented programming principles. Similar in concept to servlet filters, interceptors execute logic before and after an action method is invoked. However, unlike filters that operate at the servlet container level, Struts2 interceptors are tightly integrated with the framework’s action lifecycle and can access the value stack, action context, and other framework-specific constructs.

Struts2 provides a rich set of built-in interceptors—such as those for validation, file upload, internationalization (i18n), and model-driven data binding—which are preconfigured in struts-default.xml. These interceptors are often grouped into reusable stacks like defaultStack, validationWorkflowStack, and fileUploadStack, allowing developers to apply common behavior patterns with minimal configuration.

Common Built-in Interceptors

Example: Preventing Duplicate Submissions with TokenInterceptor

The TokenInterceptor ensures a form is submitted only once. It works by embedding a unique token in the form (via <s:token/>) and validating it on submission.

Action class:

public class RegistrationAction extends ActionSupport {
    private String username;
    
    public String getUsername() { return username; }
    public void setUsername(String username) { this.username = username; }

    @Override
    public String execute() {
        return SUCCESS;
    }
}

JSP form:

<s:form action="register">
  <s:token/>
  <s:textfield name="username" label="Username"/>
  <s:submit value="Register"/>
</s:form>

struts.xml configuration:

<action name="register" class="RegistrationAction">
  <interceptor-ref name="token"/>
  <interceptor-ref name="basicStack"/>
  <result name="success">/success.jsp</result>
  <result name="input">/register.jsp</result>
  <result name="invalid.token">/duplicate.jsp</result>
</action>

If the user refreshes after submission, the token becomes invalid, and the request is routed to invalid.token.

Creating a Custom Interceptor

To build a custom interceptor, extend AbstractInterceptor and override the intercept() method. The init() and destroy() methods support lifecycle management.

Example: Session-based authentication interceptor

public class AuthInterceptor extends AbstractInterceptor {
    @Override
    public String intercept(ActionInvocation invocation) throws Exception {
        Map<String, Object> session = invocation.getInvocationContext().getSession();
        if (session.get("user") == null) {
            return "notLoggedIn";
        }
        return invocation.invoke(); // proceed to action
    }
}

struts.xml setup:

<package name="secured" extends="struts-default">
  <interceptors>
    <interceptor name="auth" class="AuthInterceptor"/>
    <interceptor-stack name="secureStack">
      <interceptor-ref name="defaultStack"/>
      <interceptor-ref name="auth"/>
    </interceptor-stack>
  </interceptors>

  <global-results>
    <result name="notLoggedIn">/login-required.jsp</result>
  </global-results>

  <action name="dashboard" class="DashboardAction">
    <interceptor-ref name="secureStack"/>
    <result>/dashboard.jsp</result>
  </action>
</package>

Interceptors vs. Servlet Filters

• Execution model: Filters use callback (doFilter); interceptors use Java reflection and the action invocation chain.
• Container dependency: Filters require a servlet container; interceptors are framework-managed and container-agnostic.
• Scope: Filters can protect any resource (HTML, images, etc.) via URL patterns; interceptors only apply to Struts2 actions.
• Context access: Interceptors can access the value stack, action context, and OGNL expressions; filters cannot.
• Lifecycel: A filter’s init() runs once at deployment; interceptors can be instantiated per request or reused, with init()/destroy() called per instance lifecycle.
• Flexibility: Interceptor stacks allow fine-grained composition per action; filters apply globally based on URL mappings.