JSP — JavaServer Pages

🎯Learning Objectives

• JSP, now specified as Jakarta Pages, builds response content on the server.
• This lesson connects a controller’s accepted model to a readable view using directives, Expression Language and tag actions.
• You will distinguish server execution from browser execution and choose an explicit model scope.

• Our example is a fictional study report.
• The controller supplies a learner and a bounded list of courses; the view displays a summary, completion labels or an empty result.
• The lab is a JavaScript model, not a JSP engine, compiler or servlet container.

🖥️JSP Executes on the Server

• A browser requests an application URL.
• A controller can prepare data and forward internally to a JSP view.
• The server evaluates that view and sends generated response content; the browser receives the result rather than executing JSP directives or Java code.

• The generated HTML may load CSS and JavaScript, which the browser then handles normally.
• JSP and browser JavaScript therefore act at different stages.
• A JavaScript click handler cannot directly call a Java method embedded in a JSP without a separate server interaction.

• Uploading a .jsp file to a static frontend does not make it dynamic.
• A matched Java toolchain, JSP-capable web runtime and application dependencies are required.
• This website lesson publishes teaching HTML and a local demonstration only.

⚙️Translation, Compilation and Request Processing

• A JSP processor translates a page into a servlet-style implementation and compiles it for execution.
• Translation can happen ahead of requests or when required by the runtime.
• It is not accurate to assume the source is translated anew for every visit.

• The generated component has initialization and destruction hooks, while the processor generates request-service logic.
• Page authors should not define their own _jspService implementation in a JSP page.
• Keep application initialization and resource ownership in suitable managed components.

• A directive or unknown tag can fail during translation, while data access or property evaluation can fail during a request.
• Those are different boundaries; a browser preview of an HTML fragment does not prove the JSP source compiles.

• The lab intentionally skips translation and compilation.
• Its fixed HTML renderer demonstrates output decisions and rejects an unacceptable model.
• It is not a general JSP or EL interpreter.

🏗️Anatomy of a JSP Page

• Template text contributes ordinary response markup.
• A page directive declares page-level settings.
• A taglib directive associates a prefix with a tag library.
• Expression Language reads model values, and actions can render conditional or repeated content.

• The following small page assumes the controller has set a request attribute named lessonReport.
• It declares source and response encodings explicitly and uses c:out for the learner in HTML text.
• The tag library URI identifies a library; it is not a browser script download.

• The Jakarta Tags implementation must be available to the application.
• A Servlet/JSP container does not by itself guarantee that every external tag library is installed.

<%@ page contentType="text/html; charset=UTF-8"
         pageEncoding="UTF-8" session="false" %>
<%@ taglib prefix="c" uri="jakarta.tags.core" %>
<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><title>Study report</title></head>
<body>
  <h1>Study report</h1>
  <p>Learner: <c:out value="${requestScope.lessonReport.learner}" /></p>
</body>
</html>

• session="false" is suitable for this request-only view when it does not need a session.
• The scope-collision lab separately models a session-scoped attribute to teach name lookup; it does not imply this request-only page enables session access.

📜Directives and Character Encodings

• The page directive controls settings such as pageEncoding and contentType.
• Source encoding determines how the processor reads the JSP file; response encoding determines how the output bytes represent characters.
• A meta charset in HTML helps the browser but cannot repair source bytes decoded incorrectly on the server.

• The taglib directive introduces a prefix such as c for Jakarta Tags core actions.
• The include directive combines another resource’s source at translation time.
• These directives configure processing rather than directly rendering a visible control.

• Modern Jakarta examples and older Java EE/JSTL examples have compatibility differences.
• Match the page syntax, tag-library implementation, API namespace, Java version and container.
• Do not fix a missing library by mechanically renaming every package or URI.

<%@ page pageEncoding="UTF-8"
         contentType="text/html; charset=UTF-8" %>
<%@ taglib prefix="c" uri="jakarta.tags.core" %>
<%@ include file="fragments/banner.jspf" %>

• The include fragment is an illustrative dependency, not a file added to this frontend patch.
• In a real project it must exist and be compatible with the translation unit.
• Keep directive settings consistent across included source.

🧮Expressions, Scriptlets and Declarations

• Older JSP code can contain a Java expression that writes its result, a scriptlet containing request-time Java statements, and a declaration that adds members to the generated class.
• Recognizing these forms helps you read legacy pages without treating them as the preferred place for application logic.

• A declaration can create shared instance state.
• A mutable current learner field has the same concurrency danger explained in Level 23.
• SQL, authentication and business mutation should not be scattered through page scriptlets.

• Prefer a controller and service that prepare an accepted model, with EL and tags for presentation.
• JSP syntax does not automatically validate incoming values or encode Java expression output safely for HTML.

<%-- Syntax recognition only; avoid business logic in the page. --%>
<%= 2 + 3 %>                <%-- Java expression output --%>
<% int localCount = 3; %>   <%-- Scriptlet statement --%>
<%! private int count; %>   <%-- Shared member: concurrency concern --%>

<%-- Preferred presentation of an accepted model value: --%>
<c:out value="${requestScope.lessonReport.learner}" />

• The declaration is shown as a warning example, not an implementation recommendation.
• The lab never executes these scripting elements.

🧩Expression Language and Model Properties

• An EL expression such as ${requestScope.lessonReport.learner} reads a property from a scoped model.
• For a conventional JavaBean, a learner property can be exposed by a public getLearner method.
• Map keys can also be accessed through EL; the backing object’s type matters.

• EL is not JavaScript.
• Do not assume browser object semantics, arbitrary Java statements or DOM operations work inside an EL expression.
• In template text, displaying a value through EL alone is not automatic HTML escaping.

• Give the view a stable contract rather than making it guess between raw parameters, missing fields and database rows.
• The study report contract supplies a learner string and a list of courses with title and completed properties.

// Illustrative JavaBean getter within a report model class:
public String getLearner() {
    return learner;
}

// Controller fragment after validation and service work:
request.setAttribute("lessonReport", acceptedReport);

// In the view:
// ${requestScope.lessonReport.learner}

• The getter and controller lines are fragments that need their surrounding Java classes and handler.
• The JavaScript lab uses plain objects to simulate an accepted model; it does not verify JavaBean resolution in a real JSP engine.

📦Scopes and Name Collisions

• JSP scoped attributes can live in page, request, session or application scope.
• For an ordinary unqualified scoped attribute name, lookup searches page, request, session and application in that order.
• An explicit requestScope lookup states which scope the view expects.

• If the controller forgets the request attribute, an unqualified lessonReport might resolve to a session attribute with the same name.
• A page-scoped attribute can also shadow the intended request model.
• This can produce plausible but wrong output instead of an obvious missing-model failure.

• The lab contrasts one exact qualified lookup with one exact unqualified attribute lookup.
• It does not implement all EL identifiers, implicit objects, nested expressions or coercion rules.
• Its session model is fixed teaching data, not a real session.

• The default request-qualified mode ignores the page collision and session fallback.
• If its request model is missing, the lab returns a simulated 500 before rendering.
• A real JSP may display an empty value for a missing expression; this guard is an application contract in the model, not a guarantee supplied by EL.

• JSP also provides implicit objects for scripting contexts, including request, response, out, pageContext, application and config.
• The session object depends on session support; exception is available for an error page configured appropriately.
• EL has its own implicit names such as requestScope, param and paramValues, so do not treat the two sets as identical.

• param contains incoming request values and paramValues exposes repeated values.
• They are input, not the controller’s accepted report model.
• A submitted name or cookie is not proof of permission; validate input and authorize protected operations before choosing view data.

🔁Core Tags: Loop Through Accepted Data

• c:forEach repeats a body for items in a collection.
• Keep each row’s presentation simple: render the title and a controlled completion label.
• The collection should already meet the application’s model contract before the view receives it.

• c:out escapes XML-sensitive characters by default and is appropriate here for plain HTML text.
• It is not a universal encoder for JavaScript strings, CSS or arbitrary URLs.
• Choosing the destination context remains part of correct output handling.

• The following fragment reads explicitly from request scope.
• Its row variable is local to the iteration flow; it is not the same as a permanent learner field on a servlet.

<ul>
  <c:forEach var="course" items="${requestScope.lessonReport.courses}">
    <li>
      <c:out value="${course.title}" />
      <c:choose>
        <c:when test="${course.completed}"> — Complete</c:when>
        <c:otherwise> — Pending</c:otherwise>
      </c:choose>
    </li>
  </c:forEach>
</ul>

• The lab’s normal rows are Java Servlets (complete), JSP <Views> (pending) and JDBC & SQL (pending).
• The source escapes the special characters while the safe preview shows the titles literally.

🌿Conditions and Empty States

• c:if conditionally includes its body. c:choose with c:when and c:otherwise selects a branch.
• These tags suit presentation decisions such as an empty list message or a completed/pending label; they should not replace backend authorization.

• An empty collection can be accepted data.
• A view should complete with a clear message instead of showing a permanently loading box.
• A missing controller model and an accepted empty model are different outcomes.

• The lab renders an accepted empty report with 200 and a zero-course summary.
• A malformed report returns 500 with no accepted model or course preview.
• The application decides these outcomes; JSP does not automatically impose them.

<c:choose>
  <c:when test="${empty requestScope.lessonReport.courses}">
    <p>No courses in this report.</p>
  </c:when>
  <c:otherwise>
    <%-- Render the accepted list with c:forEach here. --%>
  </c:otherwise>
</c:choose>

• Validate that the model exists separately.
• The empty operator is useful for presentation, but it should not silently make an absent model look like a legitimate zero-result report when the controller contract requires one.

🧱Includes, Fragments and Reusable Views

• The include directive inserts source during translation.
• The jsp:include action includes the output of another resource at request time.
• One combines source into a translation unit; the other dispatches for output while handling the current request.

• Use a fragment for genuinely shared view markup and keep its assumptions documented.
• A source include can bring declarations and directives into the same unit, so it is not simply a runtime request to a separate page.

• A dynamic include is still server-side processing.
• It does not mean the browser fetches an iframe or imports a JavaScript module.
• Do not use a fragment to bypass validation or access-control boundaries.

<%-- Translation-time source inclusion: --%>
<%@ include file="fragments/banner.jspf" %>

<%-- Request-time output inclusion: --%>
<jsp:include page="/WEB-INF/views/fragments/help.jsp" />

• These paths are illustrative dependencies for a real application.
• This static lesson patch adds neither a JSP server nor those fragment files.
• The global header/footer on this lesson remain the existing CodeBhavya frontend components.

🧭MVC: Let the Controller Prepare the View

• A controller reads and validates request input, a service prepares application data, and the view renders an accepted report.
• This keeps persistence, permission and mutation logic out of the template and makes missing-model failures easier to locate.

• An internal forward retains the same request and its attributes.
• Keeping the JSP under WEB-INF makes the controller the intended entry point because the view is not served as an ordinary direct resource.
• This arrangement does not replace authorization for protected operations.

• A redirect creates a new client request; it does not automatically carry the previous request attributes.
• Use a deliberate read endpoint or other state mechanism rather than assuming an accepted model appears after any navigation.

// Illustrative controller fragment; acceptedReport is prepared first.
request.setAttribute("lessonReport", acceptedReport);
request.getRequestDispatcher("/WEB-INF/views/study-report.jsp")
       .forward(request, response);
// Forward before committing response output.

🛡️Literal Text and Output Contexts

• Treat learner labels and course titles as data.
• HTML text such as <Demo> must remain literal, even if it resembles a tag.
• Encoding in the response source and safe DOM rendering in the browser are separate checks.

• The lab’s renderer escapes ampersands, angle brackets and quotes in text output.
• Its preview independently constructs fixed elements and sets textContent.
• It never inserts generated HTML with innerHTML or evaluates a submitted expression.

• The fixed report has no dynamic link URLs, inline scripts or style values.
• If a real view introduces those contexts, it needs the appropriate validation and encoding rather than assuming c:out solves every destination.

<p>Learner: <c:out value="${requestScope.lessonReport.learner}" /></p>

<%-- JSP comments are not ordinary response HTML comments. --%>
<%-- Keep credentials and private diagnostics out of the source anyway. --%>

<!-- HTML comments can be present in the generated response. -->

• Do not turn untrusted input into JSP source or an EL expression to evaluate.
• Parameter validation controls the accepted data contract; output encoding controls how that accepted data appears in a specific destination.

🛠️Translation Errors, Data Errors and Stale Views

• A missing tag-library implementation, unknown action or invalid directive can stop translation.
• A property mismatch or failed service can stop request processing.
• Investigate the actual server logs and the first failing boundary rather than changing browser CSS for a server error.

• If a learner disappears, compare the controller’s attribute name and scope with the expression in the page.
• If the wrong report appears, inspect page/session name collisions before assuming the repository returned another person’s data.

• On an error, clear the previously accepted browser result.
• A failed run should not leave older course cards looking like its successful output.
• The lab displays a stable error and removes earlier rows.

• The model validator rejects non-array course lists, sparse arrays, extra fields, non-boolean completion values and overlong or invalid strings.
• This is its explicit application guard, not a description of automatic JSP validation.

🧪Verify a JSP Application in Its Runtime

• Validate and test the controller model independently, then compile and run the actual JSP in a matched container.
• Check tag-library resolution, EL property access, UTF-8 source/output, internal forwarding and the content returned over HTTP.

• Use special-character labels and accepted empty lists alongside missing and malformed models.
• Compare the response source with the browser display.
• Confirm that a qualified request model does not accidentally pick up a session report with the same name.

• The local lab tests its own scope lookup and renderer, including model copying and stale-output clearing.
• It cannot verify JSP translation, generated servlet behavior, JavaBean resolution, cookie/session handling or server concurrency.

• Level 25 continues with JDBC and Database Connectivity.
• Keep database operations in the backend data-access layer rather than adding SQL to the JSP view.

🧪Premium Interactive — Model to JSP-Style View

• This local JavaScript model accepts GET /report with exactly one learner query string.
• The learner must trim to 2–40 Unicode code points, with no C0/C1 controls or lone surrogates.
• No Java, JSP, EL engine, HTTP request or actual session runs here.

• Compare requestScope.lessonReport with unqualified lessonReport.
• The modeled lookup searches page, request, session and application for the unqualified name.
• A page collision can shadow request data; a missing request model can fall back to a fixed session or application report.
• The default qualified lookup never falls back.

• The accepted model requires exactly learner and courses; at most eight dense rows, each exactly title and completed.
• Learner uses the same bounded text rule; titles are trimmed 1–80 Unicode code points with no controls/lone surrogates; completed is boolean.
• A derived summary counts completed and pending rows.
• Model failure returns simulated 500 before rendering.

• The template panel is explanatory JSP source.
• The generated HTML is a fixed JavaScript renderer, not evaluation of that template.
• The safe preview separately builds text nodes.
• The scope fixtures are public teaching values, not private user sessions.

No trace yet.

No scope lookup yet.

No accepted model.

No response yet.

No response body yet.

🛠️Debugging — Check the Model Before the Markup

• If qualified lookup reports a missing model, inspect the controller and dispatch rather than choosing unqualified lookup simply to suppress the error.
• A session fallback can display a different learner’s teaching fixture and hide the missing request attribute.

• If a page collision is malformed, the unqualified lookup selects that value and the application model guard fails.
• It does not continue searching for a later valid object.
• If an empty report is accepted, render the explicit zero-course message.

• A successful local preview proves neither JSP compilation nor JavaBean getters.
• Run the actual view in its matched environment and verify what the server sends.

💬Interview Questions — Flip to Explain

❓MCQ Practice — Explain JSP View Decisions

💻Extra Practice — Compare View Outcomes

📌Quick Revision

📖Glossary — Flip to Learn

🏆Final Challenge — Specify an Explicit JSP Report

• Design a controller that validates the learner, obtains bounded course data and attaches lessonReport to request scope.
• Forward before committing output to a JSP under WEB-INF.
• The view should state its source/output encoding and compatible core tag library.

• Use explicit request-scope expressions, a loop for course rows and an empty-state branch.
• Render learner labels and titles as HTML text with appropriate encoding.
• Derive counts from the accepted model instead of accepting arbitrary client totals.

• Test missing, empty and malformed models, a same-name session/page collision and special-character text.
• Separate local model checks from actual JSP compilation, EL/JavaBean lookup, tag-library resolution and HTTP response checks.

• Success criterion: explain which scope produced the report and why the generated source and visible text are both correct.
• Next: Level 25 — JDBC and Database Connectivity.