Servlets — concept walkthrough.

Where we are in the story

Day 1 told you Servlets exist. Today we open the Servlet container's doors and see what's inside. By the end you'll be able to draw the lifecycle, the dispatch flow, and the role of filters from memory.

The Servlet lifecycle

A Servlet is a Java class that the container manages over time. It has three lifecycle phases:

1. init() — called once when the Servlet is first loaded (lazily on first request, or eagerly on startup if configured). Do one-time setup: open DB connections, read config, etc.
2. service() — called for every request. Internally dispatches to doGet(), doPost(), etc. based on HTTP method. Many threads call this concurrently on the same instance.
3. destroy() — called once when the container shuts down or unloads the Servlet. Clean up.

What a Servlet looks like (read-only)

@WebServlet("/users")
public class UsersServlet extends HttpServlet {

  private UserDao userDao;

  @Override
  public void init() {
    this.userDao = new UserDao(); // shared, immutable, stateless
  }

  @Override
  protected void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException {
    String idStr = req.getParameter("id");
    User u = userDao.findById(Long.parseLong(idStr));
    res.setContentType("application/json");
    res.getWriter().write(toJson(u)); // you write Jackson manually
  }
}

Familiar? Your Spring controllers are descendants of this. @RestController + @GetMapping with @RequestParam + automatic JSON serialization is the same machinery, dressed nicer.

What the Servlet container does — recap

The container is doing a lot. The Servlet is doing one thing: compute the response.

Filters — interception around your Servlet

Sometimes you want behavior that runs around every request — authentication, logging, CORS, compression. Embedding that in every Servlet would be repetitive. The Servlet API solves this with Filters.

@WebFilter("/*")
public class AuthFilter implements Filter {
  @Override
  public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
    HttpServletRequest http = (HttpServletRequest) req;
    String token = http.getHeader("Authorization");
    if (!authService.isValid(token)) {
      ((HttpServletResponse) res).setStatus(401);
      return; // short-circuit — never calls chain.doFilter()
    }
    chain.doFilter(req, res); // pass to next filter or the Servlet
  }
}

Sessions — making HTTP feel stateful

HTTP is stateless. But web apps need to know "this request is from the same user as the last one." The Servlet API offers HttpSession:

HttpSession session = req.getSession(true); // create if absent
session.setAttribute("userId", 42L);

// later request, same session cookie:
long userId = (Long) session.getAttribute("userId");

How? The container generates a JSESSIONID cookie on first session access, sets it on the response, and uses it on subsequent requests to find the same in-memory session object.

web.xml — the XML era

Old Servlet apps had a web.xml file mapping URL patterns to Servlets and Filters:

<!-- web.xml — historical -->
<servlet>
  <servlet-name>UsersServlet</servlet-name>
  <servlet-class>com.app.UsersServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>UsersServlet</servlet-name>
  <url-pattern>/users</url-pattern>
</servlet-mapping>

Servlet 3.0 (2009) added annotations like @WebServlet, @WebFilter, @WebListener — which is what Spring eventually built on. You will not write web.xml. Recognize it in legacy code, then close the file.

The bridge to Spring

Here's the most important sentence of the day:

End of Day 12. Tomorrow: REST architecture — what 'RESTful' actually means.