Java Web Technologies

🎯Learning Objectives

Java web applications connect Java code to HTTP requests through a supported server runtime. This lesson maps the ecosystem before the next lesson develops servlet processing in more detail. You will explain the jobs of a servlet, service, repository, JSP view and JDBC connection without treating them as interchangeable components.

Our example is a public course catalog. A controller validates filters, a service asks a repository for records, and a view returns HTML or JSON. The browser lab simulates those boundaries locally; it does not run Java, compile JSP or connect to a database.

🖥️Java in a Web Application

Java source is compiled into bytecode that a Java runtime executes. In a servlet-based web application, a container accepts a request and invokes the mapped component. The browser receives the produced response rather than executing the servlet’s Java source.

Java and JavaScript are distinct languages. A Java backend can return HTML that loads ordinary browser JavaScript. It can also return JSON to a static frontend; using Java on the server does not force every page to be server-rendered.

A working Java command is not the same as a complete web environment. Compiling source requires a compiler and relevant dependencies. Running a servlet requires a compatible container or an application framework that supplies that runtime.

Uploading a .java file to a static frontend does not compile or execute it. This lesson publishes teaching HTML and JavaScript; it does not change the frontend hosting into a Java server.

🧩The Main Technologies and Their Roles

A Servlet handles requests through a container-managed Java component. JSP, now specified as Jakarta Pages, provides a server-side page technology for constructing a view. JDBC is the Java database-access API used with an appropriate driver and data source.

A service and repository are application design roles rather than mandatory classes supplied by one specification. Keeping them separate helps a controller stay focused on request handling while business and data-access logic can be tested independently.

A framework can organize these responsibilities differently, but the boundaries remain useful: incoming data is not already a business model, and a template is not the right place to decide whether a caller may change a protected record.

The lab’s repository is a fixed local fixture. It has no SQL connection. The data panel and trace show the conceptual boundary so you can explain where a real JDBC implementation would fit.

📦Java EE, Jakarta EE and Namespace Compatibility

Older Java EE servlet examples commonly import javax.servlet classes. Modern Jakarta Servlet examples use jakarta.servlet. The namespace choice must match the application’s dependencies and the target container; changing a package name in one source file does not automatically migrate an entire application.

For example, Tomcat 9 uses the older servlet namespace, while Tomcat 10 and later use Jakarta APIs. Tomcat 10.1 implements Servlet 6.0 and Pages 3.1; these are specific compatibility targets, not instructions to always select one server version.

Do not mechanically rename every javax package. JDBC types such as javax.sql.DataSource remain Java platform APIs. The servlet namespace migration does not turn that type into jakarta.sql.DataSource.

// Modern Jakarta Servlet imports:
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

// JDBC data-source API remains:
import javax.sql.DataSource;

Check the container’s supported specification level, required Java version and your project’s API dependencies together. The lesson’s servlet and JSP fragments use Jakarta-style names; legacy javax.servlet projects need their own matched setup.

🧰The Container and Component Lifecycle

A servlet container maps request paths, provides request/response objects and manages servlet lifecycle calls. A servlet’s init phase prepares it, service handles requests, and destroy is part of lifecycle cleanup. The next lesson explores those callbacks and HTTP handlers in detail.

The container can serve static resources alongside mapped components. It can also translate and compile JSP pages for server-side execution. JSP source is not a special browser language that becomes dynamic merely by being downloaded.

A servlet instance may serve concurrent requests. Do not put the current learner, selected filter or per-request output into a mutable instance field and assume each request has its own servlet object. Keep request-specific work in appropriate local variables or request attributes.

A connection pool or shared service object needs a suitable lifecycle too. A component being managed by a container does not make every object you store inside it automatically thread-safe.

🧭URL Mapping, Context Paths and HTTP Methods

A servlet mapping associates an application-relative URL pattern with a component. A deployed application can also have a context path. A browser request to /learning/catalog may reach a /catalog mapping inside the /learning application.

The servlet mapping is not simply a Java filename. The lab models GET /catalog as its only public route, with 404 for an unknown path and 405 plus Allow: GET for an unsupported method. Its routing is intentionally narrower than a complete container.

Real HttpServlet behavior includes method handling beyond this toy route, including framework/container treatment of HEAD and OPTIONS. Do not copy the simulator’s limited router as if it were a full servlet implementation.

import java.io.IOException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse res)
            throws IOException {
        res.setContentType("text/plain; charset=UTF-8");
        res.getWriter().println("Java handles this request on the server.");
    }
}

This small class requires a matching Servlet API dependency and container. It is an illustrative component, not a standalone main program or a deployed endpoint in this website.

📨Parameters Are Input; Attributes Carry a Model

Request parameters are incoming values associated with a query or supported form submission. Request attributes are objects that application components can attach while handling the request. The two serve different purposes.

The catalog controller accepts four scalar strings: category, available, limit and view. Category is all, web or backend. Available is exactly true or false. Limit is exactly 1, 2 or 3. View is jsp or json. Only after acceptance does the controller convert the boolean and limit.

A repeated query parameter can produce multiple values. The lab includes an array-valued category variant to represent that shape; it rejects the request rather than silently choosing one. A real servlet should deliberately inspect getParameterValues when uniqueness matters.

// Illustrative controller fragment:
String[] values = request.getParameterValues("category");
if (values == null || values.length != 1) {
    response.sendError(400, "One category value is required");
    return;
}
// Validate the value, call the service, then attach an accepted model.
request.setAttribute("catalog", acceptedCourses);

The fragment assumes request, response and an acceptedCourses model supplied by the surrounding handler. Request attributes survive an internal forward of that request; they are not durable browser storage or an automatic login identity.

🔄Controller, Service and Repository Boundaries

A controller decides whether input is acceptable and selects the representation. A service coordinates application behavior. A repository or DAO isolates the data-access implementation. This separation lets a service use a fake repository in tests and a database-backed implementation in a deployment.

The lab validates before calling its repository. The repository returns at most ten bounded records. The service validates that record model, filters by category and availability, then applies the accepted limit in fixture order. Filtering after the limit could accidentally hide a matching course.

No request changes course records. The visible repository call count is just a local teaching counter. Empty results are accepted data, while an unavailable repository and an unacceptable returned record are different failures.

A larger application may enforce filtering efficiently in its repository or database. The exercise keeps three fixtures in memory so the order of decisions remains visible; it is not a performance design for an unbounded catalog.

📄JSP as a Server-Side View

A JSP page is processed on the server. In a controller/view flow, the controller attaches a model and forwards to a view that focuses on presentation. Keep authorization, SQL operations and business mutations out of the page template.

Expression Language such as ${course.title} reads model properties. For conventional JavaBean-style objects, a title property is exposed through a getter such as getTitle. Do not assume that displaying an expression automatically provides the output encoding your context needs.

The following modern Jakarta Tags fragment uses c:out for HTML text and c:forEach for a catalog. The appropriate tag-library implementation must be available in the application; a servlet container alone is not a guarantee that every JSP tag library is installed.

<%@ page contentType="text/html; charset=UTF-8" %>
<%@ taglib prefix="c" uri="jakarta.tags.core" %>
<h2>Course catalog</h2>
<ul>
  <c:forEach var="course" items="${catalog}">
    <li>
      <c:out value="${course.title}" />
      — <c:out value="${course.available}" /> places
    </li>
  </c:forEach>
</ul>

This template is a teaching fragment for an accepted catalog model. The browser lab generates a simplified JSP-style HTML result using JavaScript, and it never compiles or evaluates this JSP source.

↪️Forwarding and Redirecting Are Different Flows

An internal forward passes the same request to another server resource before the response is committed. A controller can attach request attributes and forward to a JSP under WEB-INF. That view can use the model without asking the browser to issue a second request.

A redirect returns a response instructing the client to request another URL. That later request does not automatically carry the first request’s attributes. Decide how needed state is preserved instead of assuming a forward and redirect are interchangeable.

Keeping a JSP under WEB-INF helps make the controller the intended entry point because those resources are not directly served as ordinary client requests. That arrangement does not replace authorization checks at protected handlers.

// Illustrative accepted-model branch:
request.setAttribute("catalog", acceptedCourses);
request.getRequestDispatcher("/WEB-INF/views/catalog.jsp")
       .forward(request, response);
// Do this before committing response body output.

The lab’s JSP branch records a simulated internal forward; it does not navigate the browser or call RequestDispatcher. Its JSON branch instead serializes the accepted model directly. Both are deliberate response choices.

🗃️JDBC, Drivers and Prepared Statements

JDBC supplies Java APIs for connecting to a database, executing statements and reading results. A suitable driver and configured connection or DataSource are required. A JDBC API import alone does not create a database or make a connection succeed.

Use bound values in prepared statements instead of concatenating untrusted input into SQL. Parameter binding keeps a value separate from the statement’s structure; dynamic table names or arbitrary SQL fragments need different deliberate controls.

Connections, statements and result sets have lifecycles. Try-with-resources helps close owned JDBC resources. Closing a pooled connection normally returns it to its pool; pool setup and credentials belong in protected backend configuration.

// Illustrative repository fragment; dataSource is already configured.
String sql = "SELECT id, title, available FROM courses "
           + "WHERE category = ? ORDER BY id";
try (java.sql.Connection con = dataSource.getConnection();
     java.sql.PreparedStatement ps = con.prepareStatement(sql)) {
    ps.setString(1, acceptedCategory);
    try (java.sql.ResultSet rs = ps.executeQuery()) {
        while (rs.next()) {
            // Map checked columns into CourseView objects.
        }
    }
}

The lab does not execute this query or load a JDBC driver. Its repository fixtures let you test the service boundary without pretending that database availability, transactions or resource cleanup have been verified.

👤Scopes, Sessions and Shared State

Choose the lifetime of an object deliberately. Request scope suits one accepted catalog model. Session scope can hold application state associated with a user’s session. Application scope can hold shared configuration or resources, with suitable safety and lifecycle rules.

A session object does not prove permission merely because it exists. Establish a trustworthy identity and apply authorization before returning protected data or changing records. The public catalog demonstration has no login or session system.

Do not copy one request’s selected filter into a global field and let a later request accidentally reuse it. Shared collections and session attributes can be accessed concurrently and need an appropriate strategy.

The browser simulation is synchronous and local. Its tests can check that one run does not reuse an earlier model; they do not prove real servlet concurrency or distributed session behavior.

⚠️Errors, Empty Results and Representations

An empty catalog can be a successful 200 response with no matching records. Invalid query data returns 400 in this exercise. An unknown path and unsupported method have their own route outcomes. These decisions should not be collapsed into a generic database error.

The unavailable-repository fixture returns a simulated 503 without disclosing connection details. The malformed-record fixture returns 500 because the repository output fails the service’s accepted model contract. Neither outcome produces an accepted catalog view.

A JSP-style response uses text/html; a JSON response uses application/json. The caller should know which representation to parse. The Level 18 loader already illustrated why a received response, successful status and acceptable data are separate stages.

A deployed server can log private diagnostics while sending a stable public message. The lab trace is visible teaching output and is not a recommendation to expose SQL details, credentials or production stack traces.

📦Build and Deploy a Matched Application

A project needs a matched Java toolchain, web API dependencies and runtime. A WAR is one packaging option for deploying a web application to a container; some frameworks package an embedded server differently. Packaging conventions are not interchangeable with static file uploads.

A conventional layout can keep Java source under a source tree, static web assets under a web-resource tree and JSP views under WEB-INF. The exact build configuration depends on the chosen tools. Mark container-provided APIs appropriately so incompatible copies are not bundled accidentally.

Test the mapping, context path, response encoding, JSP/tag-library availability and data-source configuration in the deployed environment. A successful compile does not establish that the runtime, driver or database has been configured correctly.

Illustrative project roles:
src/main/java/.../CatalogServlet.java      controller
src/main/java/.../CatalogService.java      service
src/main/java/.../CourseRepository.java    data boundary
src/main/webapp/WEB-INF/views/catalog.jsp  view
Build configuration                       matched APIs/runtime

This lesson supplies explanatory fragments rather than a complete WAR project. No Java web server or database is deployed by the lesson patch. The next lesson builds understanding of Java Servlets before later JSP and database work.

🧪Test Boundaries Before Integrating Everything

A service can be tested with a fake repository to check valid records, empty data and failure behavior. A controller test can verify bad parameters are rejected before service access. A view test can check literal text and representation output. Real integration tests still need the container and data source.

For the catalog, test that category and availability filtering happen before limiting. Check invalid numeric spellings, duplicate-shaped parameters, missing fields and unknown view values. A repeated request should not inherit an earlier accepted model or stale HTML after a failure.

Keep the Java build and deployment checks separate from the browser lab’s automated checks. The simulation explains responsibilities and verifies its own JavaScript logic, but it does not establish Servlet, JSP, JDBC or JVM behavior.

The visualizer follows one accepted catalog request. The lab lets you change the query, repository outcome and response representation to locate the first failed boundary. Level 23 will continue with Java Servlets.

🧪Premium Interactive — Catalog Layers Demonstration

This is a JavaScript model of application layers, not a servlet container or JVM. It sends no requests, executes no SQL and stores no course changes. The repository call count is a local teaching counter that Reset clears.

The three normal records are HTML & CSS (web, 12 places), Java Servlets (backend, 8) and JSP <Views> (backend, 0). The service filters by category and availability before applying a limit. Its model validates record shape, unique IDs, bounded titles and non-negative integer availability.

Choose a JSP-style HTML response or JSON. Inspect the decoded query, trace, accepted model and response source. Empty repository data is a successful empty result; offline data returns simulated 503, and malformed data returns 500. Bad query parameters fail before repository access.

No request processed.

No trace yet.

No accepted model.

No response yet.

No response body yet.

🛠️Debugging — Locate the Layer

If a modern servlet import is unresolved, check the API dependency and target container rather than replacing every javax import blindly. If a view receives no catalog, check which request attribute the controller sets and whether the request was forwarded or redirected.

If a filter produces no matching course unexpectedly, check that limiting happens after filtering. If the view still shows an older catalog after a failure, clear the earlier model and response rather than presenting stale data as a new success.

A mock repository test does not verify a driver, connection pool or real query. A JavaScript view preview does not verify JSP compilation. Keep those integration checks explicit when building the real application.

💬Interview Questions — Flip to Explain

❓MCQ Practice — Match the Java Web Responsibility

💻Extra Practice — Trace Specific Layer Outcomes

📌Quick Revision

📖Glossary — Flip to Learn

🏆Final Challenge — Specify a Layered Java Catalog

Design a catalog controller with unique scalar category, availability, limit and representation parameters. Validate before service access. Have a service accept a bounded repository model, filter before limiting and return a clear zero-result outcome.

Specify a JSP view using an accepted request model and appropriate HTML text encoding, plus a JSON response branch. Explain forwarding versus redirecting, model scope and which pieces require a compatible Jakarta or legacy Java EE runtime.

Define separate tests for controller rejections, repository failure, malformed rows, service filtering and literal titles. A real project must then verify servlet mapping, JSP/tag libraries, JDBC driver/data source and actual HTTP output. Do not infer those integration results from this local browser demonstration.

Success criterion: map each application responsibility to the right layer and trace both accepted and rejected catalog requests. Level 23 will develop Java Servlets in more detail.