Sessions, Cookies & Filters

The Front Controller Pattern

18 min Lesson 9 of 13

The Front Controller Pattern

As a Jakarta EE web application grows, a common trap appears: every feature gets its own servlet, every servlet duplicates authentication checks, logging, and routing logic, and the codebase turns into a tangle of overlapping responsibilities. The Front Controller pattern is the architectural cure. Instead of mapping URLs directly to individual servlets, a single entry-point servlet receives every request, inspects it, and delegates to a lightweight command handler that knows only about that one use-case. Security, logging, encoding, and other cross-cutting concerns live in exactly one place.

This pattern is not academic. Every major Java web framework is built on it: Spring MVC's DispatcherServlet, Struts's ActionServlet, and JSF's FacesServlet are all Front Controllers. Learning the raw pattern gives you the mental model to understand and debug any of them.

The Problem Without a Front Controller

Imagine a simple shop application with three servlets: LoginServlet, ProductServlet, and CartServlet. Each one must check whether the user is logged in, set the response encoding, and log the request. The duplication is not just tedious — it is dangerous. When the authentication check changes, you must update three places. When you add a fourth servlet you must remember to add the cross-cutting code. You usually forget.

Structuring the Solution

The pattern has three collaborating pieces:

Front Controller Servlet — the single servlet mapped to /* (or a common prefix). It extracts a command name from the request, finds the right handler, and calls it.
Command (Handler) interface — a tiny interface every handler implements. The front controller depends only on this abstraction.
Concrete Handlers — one class per use-case (login, list products, add to cart). No servlet infrastructure; just business logic and a forward or redirect at the end.

The Command Interface

package com.example.web.command;

import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;

public interface Command {
    void execute(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException;
}

Keeping the interface this thin means handlers stay focused. They set request attributes, call service-layer methods, and then either request.getRequestDispatcher("/WEB-INF/views/foo.jsp").forward(request, response) or response.sendRedirect(...).

A Concrete Handler

package com.example.web.command;

import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;

public class ListProductsCommand implements Command {

    private final ProductService productService = new ProductService();

    @Override
    public void execute(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        var products = productService.findAll();
        request.setAttribute("products", products);
        request.getRequestDispatcher("/WEB-INF/views/products.jsp")
               .forward(request, response);
    }
}

The Front Controller Servlet

package com.example.web;

import com.example.web.command.*;
import jakarta.servlet.ServletException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.*;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

@WebServlet(urlPatterns = "/app/*")
public class FrontControllerServlet extends HttpServlet {

    // Command registry: URL path segment -> handler
    private final Map<String, Command> commands = new HashMap<>();

    @Override
    public void init() {
        commands.put("products",  new ListProductsCommand());
        commands.put("product",   new ShowProductCommand());
        commands.put("login",     new LoginCommand());
        commands.put("logout",    new LogoutCommand());
        commands.put("cart",      new CartCommand());
    }

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse res)
            throws ServletException, IOException {

        // ---- Cross-cutting concerns (run for EVERY request) ----
        res.setCharacterEncoding("UTF-8");
        req.setCharacterEncoding("UTF-8");

        // ---- Resolve command name from path info ----
        // URL: /app/products  ->  pathInfo = "/products"
        String pathInfo = req.getPathInfo();           // e.g. "/products"
        String commandName = "home";                  // default
        if (pathInfo != null && pathInfo.length() > 1) {
            commandName = pathInfo.substring(1);      // strip leading "/"
            int slash = commandName.indexOf('/');
            if (slash > 0) commandName = commandName.substring(0, slash);
        }

        // ---- Dispatch ----
        Command command = commands.get(commandName);
        if (command == null) {
            res.sendError(HttpServletResponse.SC_NOT_FOUND,
                          "Unknown command: " + commandName);
            return;
        }

        command.execute(req, res);
    }
}

Use service(), not doGet()/doPost(). Overriding service() lets the front controller pass the HTTP method through to the handler unchanged. If your handler needs to differentiate GET from POST it can read request.getMethod() itself, keeping that decision where it belongs.

Authentication in One Place

One of the biggest wins of the Front Controller is centralised authentication. Add the check to service() before dispatch, and every handler in the application is automatically protected:

private static final Set<String> PUBLIC_COMMANDS =
        Set.of("login", "register", "home");

@Override
protected void service(HttpServletRequest req, HttpServletResponse res)
        throws ServletException, IOException {

    res.setCharacterEncoding("UTF-8");
    req.setCharacterEncoding("UTF-8");

    String commandName = resolveCommand(req);

    if (!PUBLIC_COMMANDS.contains(commandName)) {
        HttpSession session = req.getSession(false);
        if (session == null || session.getAttribute("user") == null) {
            res.sendRedirect(req.getContextPath() + "/app/login");
            return;
        }
    }

    Command command = commands.get(commandName);
    if (command == null) {
        res.sendError(HttpServletResponse.SC_NOT_FOUND);
        return;
    }
    command.execute(req, res);
}

Handling POST vs GET in Handlers

A handler that manages a form typically responds differently depending on the HTTP method — GET renders the empty form, POST processes the submission and redirects. The handler does this cleanly without any servlet infrastructure:

public class LoginCommand implements Command {

    private final UserService userService = new UserService();

    @Override
    public void execute(HttpServletRequest req, HttpServletResponse res)
            throws ServletException, IOException {

        if ("POST".equalsIgnoreCase(req.getMethod())) {
            String username = req.getParameter("username");
            String password = req.getParameter("password");
            var user = userService.authenticate(username, password);
            if (user != null) {
                req.getSession(true).setAttribute("user", user);
                res.sendRedirect(req.getContextPath() + "/app/products");
            } else {
                req.setAttribute("error", "Invalid credentials");
                req.getRequestDispatcher("/WEB-INF/views/login.jsp")
                   .forward(req, res);
            }
        } else {
            req.getRequestDispatcher("/WEB-INF/views/login.jsp")
               .forward(req, res);
        }
    }
}

Trade-offs and When to Use It

Pro: Cross-cutting concerns (auth, encoding, logging, CSRF) live in exactly one class.
Pro: Adding a new use-case means adding one handler class and one line in the command registry — no new servlet, no new URL mapping.
Pro: Handlers are plain Java objects; they are easy to unit-test without a servlet container.
Con: The command registry in init() can grow large. In a mature application you would replace the manual map with reflection-based auto-discovery or a dependency-injection container.
Con: Mapping one URL pattern to all commands means the HTTP method semantics of individual endpoints are less explicit to the container. Document your conventions clearly.

Never put business logic inside the Front Controller itself. If your FrontControllerServlet starts doing database lookups or building HTML, you have recreated the original problem in a single class. The Front Controller's only job is to route and apply cross-cutting concerns.

Evolving Toward Frameworks

What you have built is a miniature DispatcherServlet. Spring MVC adds annotation scanning (@GetMapping, @PostMapping), argument resolvers, view resolvers, and interceptors — but the dispatch loop in the centre is exactly this pattern. Understanding the raw version means you can read Spring's source code, configure it correctly, and diagnose subtle routing bugs instead of being mystified by them.

Summary

The Front Controller pattern solves the cross-cutting duplication problem by funnelling all requests through a single dispatch servlet. That servlet resolves a command name from the URL, applies shared concerns (authentication, encoding), and delegates to a thin Command handler. The result is a codebase where adding a feature means adding one class, and where security or logging changes happen in exactly one place. In the final lesson of this tutorial you will combine sessions, filters, and the Front Controller into a complete login-and-protected-area project.