Java Omnibus
OOAD & Architecture / J2EE / Jakarta EE Patterns / Intercepting Filter Pattern
J2EE Presentation Java Order Management
Presentation

Intercepting Filter Pattern

Intercepting Filter creates a reusable pipeline for cross-cutting request concerns so individual handlers do not each own authentication, logging, normalization, or tracing logic.

Why This Topic Matters

Why it matters in enterprise Java

In order management flows, checkout and account operations often need security checks, locale setup, correlation IDs, and auditing. Filters let those concerns run consistently before the business handler.

Pattern Essentials

Intent, problem, and solution

Intent

What the pattern is trying to achieve

Create a configurable pipeline of reusable request-processing steps that run before or around the main handler.

Problem

What goes wrong without it

Cross-cutting request logic gets duplicated across controllers, servlets, or endpoints.

Solution

How the pattern answers the problem

Arrange reusable filters that inspect or modify the request and then delegate forward through a chain.

Modern Relevance

Why it still matters now

The pattern remains highly relevant in servlet stacks, Spring Security, API gateways, and observability pipelines.

Structure

How the collaboration works

  • A request enters a filter chain before reaching the main handler.
  • Each filter handles one cross-cutting concern.
  • The chain preserves order, which is often semantically important.
  • The final handler sees a prepared, normalized request context.
Java Example

Java example in the Order Management domain

Java example: tracing and tenant context filters
package org.javaomnibus.ecommerce.web;

import jakarta.servlet.Filter;
import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.ServletRequest;
import jakarta.servlet.ServletResponse;
import java.io.IOException;
import java.util.Locale;
import java.util.UUID;

public final class CorrelationFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
        request.setAttribute("correlationId", UUID.randomUUID().toString());
        request.setAttribute("locale", Locale.US);
        chain.doFilter(request, response);
    }
}
Code Walkthrough

Step by step

  1. The filter enriches the request before delegating onward.
  2. The handler does not need to know how correlation or locale setup happens.
  3. Multiple filters can be chained for security, tracing, or request normalization.
  4. Order remains a first-class design choice because some filters depend on earlier setup.
Real-World Usage

Where this pattern shows up

  • Servlet filters and Spring Security chains
  • Request tracing, auditing, and compression
  • Multi-tenant request decoration
When Not To Use

Cases where another shape is better

  • Business rules that belong inside application services rather than request infrastructure
  • One-off request behaviors that do not justify reusable pipeline stages
Trade-Offs

Trade-offs and design pressure

  • Filter order can become subtle and fragile without strong conventions.
  • Debugging deep chains can be harder if cross-cutting logic becomes too opaque.
Comparison Note

How this differs from nearby patterns

Use Intercepting Filter for reusable infrastructure concerns. Use Front Controller for central request routing and high-level web coordination.

Common Misuse

Mistakes to avoid

  • Embedding business decisions into filters
  • Creating too many micro-filters with unclear ownership
  • Allowing filters to mutate domain-relevant state unpredictably
Related Pages

Related concepts


What To Read Next