Context & Deployment

What is a Context — and Why Does Deployment Need One?

Every earlier page in this topic described a piece of the machinery — the container, the archive format, the XML configuration. A Context is where all of it becomes one running, addressable, isolated application: it's the container's runtime representation of a single deployed WAR, with its own URL namespace, its own classloader, and its own ServletContext object. Without a Context, a compiled application is just bytes sitting in a directory — nothing gives it a URL, nothing isolates its classes from another application's, and nothing manages its start/stop lifecycle independently of the rest of the server.

// BEFORE deployment — compiled classes and a WAR file, addressable by nothing
target/myapp.war
// This file has no URL, no running classloader, no lifecycle. It's inert.

// AFTER deployment — the container creates a Context from it
$ cp target/myapp.war /opt/tomcat/webapps/
// The container now maintains, for this one application specifically:
//   - a context path:      /myapp
//   - an isolated classloader: WEB-INF/classes and WEB-INF/lib resolve
//     here first, independent of any other deployed application
//   - a live ServletContext object your code can query at runtime
//   - a start/stop/reload lifecycle independent of every other Context
// http://localhost:8080/myapp/products/list is now a real, addressable request

Reading the context path out of a URL

http://localhost:8080/myapp/products/list
                       └────┬────┘└──┬──┘└──────┬──────┘
                        Host:Port  Context    Path within
                                    Path      the application

# myapp.war → context path /myapp (the WAR's filename determines this by default)

The ServletContext Object

public class CatalogServlet extends HttpServlet {

    @Override
    public void init() throws ServletException {
        ServletContext ctx = getServletContext();

        String adminEmail = ctx.getInitParameter("admin.email");          // from web.xml <context-param>
        ctx.setAttribute("catalogCache", new CatalogCache());        // shared across every servlet in this Context
        String uploadDir = ctx.getRealPath("/uploads");                     // resolves to an actual filesystem path
        ctx.log("CatalogServlet initialized");                              // writes to this Context's own log
    }
}

Deployment Methods

WAR drop (most common for a single standalone instance)

cp myapp.war $CATALINA_HOME/webapps/
# Detected, extracted to webapps/myapp/, deployed, live at /myapp

Exploded directory (development convenience)

webapps/myapp/
├── WEB-INF/{web.xml, classes/, lib/}
├── index.html
└── css/
# Edit files directly without rebuilding the WAR — faster iteration locally,
# not a pattern to rely on for any real deployment

Context XML file (per-application configuration, outside web.xml)

<!-- $CATALINA_HOME/conf/Catalina/localhost/myapp.xml -->
<Context docBase="/path/to/myapp.war" reloadable="false">
    <Resource name="jdbc/shopDB" auth="Container" type="javax.sql.DataSource"
              driverClassName="org.postgresql.Driver"
              url="jdbc:postgresql://db.internal:5432/shop"
              username="${DB_USER}" password="${DB_PASSWORD}"
              maxTotal="100" maxIdle="30"/>
    <Environment name="maxUploadSize" value="10485760" type="java.lang.Integer"/>
</Context>

Tomcat Manager

# http://localhost:8080/manager/html — GUI deployment
# Or the text interface, scriptable from CI:
curl -u deploy-bot:${MANAGER_PASSWORD} \
     -T myapp.war \
     "http://localhost:8080/manager/text/deploy?path=/myapp&update=true"
# Credential hardening for this account is covered on Tomcat Overview —
# narrow role, digest-hashed password, IP-restricted access

Looking Up JNDI Resources

The <Resource> declared in the Context XML above is exactly the mechanism referenced on What is an Application Server? — the server owns the actual connection details, and application code looks the resource up by name rather than hardcoding them.

public class CatalogServlet extends HttpServlet {

    private DataSource dataSource;

    @Override
    public void init() throws ServletException {
        try {
            Context initCtx = new InitialContext();
            Context envCtx = (Context) initCtx.lookup("java:comp/env");
            dataSource = (DataSource) envCtx.lookup("jdbc/shopDB");
        } catch (NamingException e) {
            throw new ServletException("Cannot find DataSource", e);
        }
    }
}

Hot Deployment

<!-- context.xml or server.xml Host element -->
<Context reloadable="true">   <!-- watches WEB-INF/classes and WEB-INF/lib for changes -->
</Context>

Production Deployment Strategies

Stop → deploy → start (simple, brief downtime)

curl "http://localhost:8080/manager/text/stop?path=/myapp"
curl -T myapp.war "http://localhost:8080/manager/text/deploy?path=/myapp&update=true"
curl "http://localhost:8080/manager/text/start?path=/myapp"

Parallel deployment (zero downtime, Tomcat-specific)

# Version-in-filename: appname##version.war
myapp##001.war   → the currently active version
myapp##002.war   → the new version, deployed alongside it

# Existing sessions continue on their original version; new sessions go to
# the newest one; the old version undeploys automatically once its last
# session ends — no request is ever dropped mid-flight.

Blue-green deployment (two full environments, instant rollback)

# BLUE (current) stays serving traffic while GREEN (new version) is deployed
# and tested independently. A load balancer switch moves traffic to GREEN;
# BLUE stays warm and ready for an instant rollback if GREEN misbehaves.

Classloading and Isolation — and the Memory Leak That Follows From It

Bootstrap ClassLoader
    └── System ClassLoader
        └── Common ClassLoader ($CATALINA_HOME/lib — shared across ALL apps)
            ├── WebApp1 ClassLoader (WEB-INF/classes, WEB-INF/lib)
            ├── WebApp2 ClassLoader (WEB-INF/classes, WEB-INF/lib)
            └── WebApp3 ClassLoader (WEB-INF/classes, WEB-INF/lib)

// Each Context gets its OWN classloader, checked before delegating up to
// the shared Common one. Two apps can depend on conflicting versions of the
// same library without interfering — this is the mechanism referenced on
// Tomcat Overview for exactly this scenario.

@WebListener
public class CleanupListener implements ServletContextListener {

    @Override
    public void contextDestroyed(ServletContextEvent event) {
        executorService.shutdown();   // stop any thread this Context started

        // Deregister JDBC drivers THIS context registered — DriverManager's list
        // is JVM-wide, shared across every deployed Context, so a driver
        // registered here but never deregistered outlives this Context entirely
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver driver = drivers.nextElement();
            try {
                DriverManager.deregisterDriver(driver);
            } catch (SQLException e) {
                log.warn("Error deregistering driver", e);
            }
        }

        connectionPool.close();   // release pooled connections rather than leaving them open
    }
}

Spring Boot Context Configuration

# application.yml
server:
  port: 8080
  servlet:
    context-path: /shop
    session:
      timeout: 30m
      cookie:
        http-only: true
        secure: true
  tomcat:
    threads:
      max: 200
      min-spare: 10

Session cookie hardening here follows the exact same reasoning as Session Management; thread pool sizing and when to prefer Virtual Threads instead of raising server.tomcat.threads.max is covered in depth on What is an Application Server?.

Best Practices and Common Pitfalls

Interview Questions