Intro

If your Java web app is a messy party where every action repeats the same small talk then interceptors are the bouncers you need. Apache Struts interceptors let you run common logic around action execution so you do not paste the same code into every class. This short tutorial covers purpose configuration a custom interceptor and how to attach and test it in a Struts2 MVC setup.

What interceptors actually do

Interceptors wrap action execution to handle cross cutting concerns like authentication logging timing and request preprocessing and postprocessing. Think request goes in then interceptors get to peek adjust or veto things before your action runs and then they can inspect or transform the response after the action returns.

Configure interceptors in struts.xml

In struts.xml you declare interceptor entries and interceptor stacks then reference a stack from an action or a package. The order you list interceptors is the order they run before the action and the reverse order after the action completes. A minimal configuration looks like this example.

<struts>
  <package name="default" namespace="/" extends="struts-default">
    <interceptor name="logging" class="com.example.LoggingInterceptor" />
    <interceptor-stack name="customStack">
      <interceptor-ref name="logging" />
      <interceptor-ref name="defaultStack" />
    </interceptor-stack>

    <action name="hello" class="com.example.HelloAction">
      <result>hello.jsp</result>
    </action>
  </package>
</struts>

Implement a custom interceptor

For a custom interceptor extend com.opensymphony.xwork2.interceptor.AbstractInterceptor or implement the Interceptor interface. Override the intercept method and be polite about continuing the chain by calling invocation.invoke() when you want the action to run. Manage resources handle exceptions and avoid swallowing failures like a code kamikaze.

Example behavior to implement

• Do quick checks before the action runs for authentication or parameter normalization
• Call invocation.invoke() to let the next interceptor or the action run
• Inspect the result after invocation.invoke and perform logging timing or response transformation

Attach interceptors to actions or packages

You can apply an interceptor stack to a single action or to a package so many actions inherit it. Use include and exclude patterns when you want certain actions to skip the logic. This prevents surprising side effects when multiple stacks are combined.

Test and debug interceptor flow

Run the app and trace logs to verify pre processing and post processing stages. Typical failure modes are wrong class names missing mapping and forgetting invocation.invoke. If the debugger feels cooperative set breakpoints inside your intercept method and step through the chain. Logging entry and exit points is a small investment that pays in debugging time saved.

Common gotchas

• Order matters. The stack order controls both pre and post processing flow
• Keep interceptors single purpose and small. Smaller spies are easier to reason about
• A global interceptor for sensitive checks can be surprising. Prefer explicit checks where needed
• Remember to clean up resources and to catch and rethrow or handle exceptions properly

Quick checklist before you push

• Declared interceptor entries in struts.xml
• Added interceptor stack and referenced it from actions or packages
• Implemented intercept method and called invocation.invoke()
• Tested with logs and breakpoints to confirm both pre and post behavior

Summary

Interceptors in Struts2 give you a clean place for request preprocessing and postprocessing so your actions do what they were meant to do without boilerplate code. Configure stacks in struts.xml implement a small focused custom interceptor and attach it to the right actions. Follow the checklist above and your Java web app will behave more predictably and you will spend less time fixing duplicated code and more time doing things that actually matter.