Common Mistakes & Best Practices
A consolidated review of JSP pitfalls to avoid — scriptlets versus EL/JSTL, keeping logic out of views, and common Tomcat deployment mistakes.
Introduction
You have now seen every major piece of JSP individually. This lesson steps back and consolidates the lessons learned across the whole course into a single reference: the habits that separate fragile, legacy-feeling JSP code from clean, maintainable applications, plus the deployment mistakes that trip up almost everyone the first time they run a JSP app on Tomcat.
- Why scriptlets should almost never appear in modern JSP.
- How to keep business and data-access logic out of views.
- The most common Tomcat deployment mistakes.
- A consolidated checklist to review before shipping a JSP application.
Avoid Scriptlets, Prefer EL and JSTL
Scriptlets (<% ... %>) mix raw Java into HTML, making pages hard to read, hard to test, and impossible for a front-end-only developer to safely edit. Every scriptlet you have seen used for teaching in this course has a cleaner EL or JSTL equivalent in real code.
<% if (request.getAttribute("user") != null) { out.println("Welcome, " + request.getAttribute("user")); }%><c:if test="${not empty user}"> <p>Welcome, ${user}</p></c:if>Keep Business Logic Out of JSP
A JSP file should describe what the page looks like, not how the application works. Database queries, calculations, and validation rules belong in servlets, service classes, or JavaBeans — never directly in the view, even when EL makes it technically possible to call almost any method.
| Belongs In the View (JSP) | Belongs In the Controller/Service |
|---|---|
| Looping over a list with c:forEach | Fetching that list from a database |
| Formatting a date with fmt:formatDate | Deciding which date to show |
| Showing/hiding a section with c:if | Deciding the business rule behind the condition |
| Reading ${student.name} | Validating and constructing the student object |
Common Tomcat Deployment Mistakes
Even correct JSP code can fail to run because of packaging or configuration issues. These are the mistakes that account for most "it works on my machine" reports.
| Mistake | Symptom | Fix |
|---|---|---|
| JAR files placed outside WEB-INF/lib | ClassNotFoundException at runtime | Move all dependency JARs into WEB-INF/lib |
| Wrong or missing web.xml servlet mapping | 404 on a servlet URL that should exist | Verify @WebServlet path or <url-pattern> in web.xml |
| Stale compiled classes after a change | Old behavior persists after redeploy | Clean Tomcat's work directory and redeploy |
| Case-sensitive path mismatch on Linux servers | Works locally on Windows, fails in production | Match file and folder casing exactly everywhere |
| Session-breaking redeploys during testing | Users unexpectedly logged out mid-test | Avoid hot redeploys against a session you are actively testing |
Security Basics
- Escape all user-supplied output to prevent cross-site scripting — <c:out value="${userInput}" /> escapes HTML by default, while raw ${userInput} does not.
- Always use POST, never GET, for anything that changes state or carries sensitive data.
- Validate and sanitize form input on the server, never trust client-side validation alone.
- Never expose stack traces or internal paths to end users, as covered in the error handling lesson.
<!-- Safe: escapes HTML/script characters --><p>Comment: <c:out value="${comment}" /></p>
<!-- Unsafe if comment contains a <script> tag --><p>Comment: ${comment}</p>Performance Considerations
- Prefer the include directive over jsp:include for genuinely static fragments to skip the per-request call overhead.
- Keep sessions lean — large session objects multiply across every concurrent logged-in user.
- Cache expensive, rarely-changing lookups at application scope rather than recomputing them per request.
- Avoid unnecessary nested c:forEach loops over large collections directly in the view; paginate or precompute instead.
Common Mistakes
- Writing new JSP pages full of scriptlets in 2026 because an old tutorial did it that way.
- Putting SQL queries directly inside a JSP file.
- Forgetting <c:out> or the fn:escapeXml equivalent when echoing user input.
- Deploying without cleaning Tomcat's work directory after major changes and chasing a "ghost bug" that is really just a stale class.
Best Practices Checklist
- No scriptlets in new code — EL and JSTL cover the vast majority of real needs.
- All dynamic output that came from a user is escaped before display.
- All state-changing actions use POST, and follow the Post/Redirect/Get pattern to avoid duplicate submits.
- Business and data-access logic lives in servlets/services, never in the JSP itself.
- Dependency JARs sit correctly in WEB-INF/lib and match the classes referenced.
- An application-wide error page is configured in web.xml.
Frequently Asked Questions
Many new projects reach for other stacks, but a huge amount of enterprise Java software still runs on JSP, and understanding it well is directly useful for maintaining and modernizing that code.
Extremely rarely — nearly everything is covered by EL, JSTL, and custom tags. Reach for a scriptlet only as a last resort, and consider whether the logic actually belongs in a servlet instead.
Unescaped user input causing cross-site scripting, closely followed by stale compiled classes after a redeploy.
Key Takeaways
- EL and JSTL should replace scriptlets in essentially all modern JSP code.
- Views render data; controllers and services own the logic behind it.
- Most Tomcat deployment failures trace back to JAR placement or stale compiled classes.
- Escaping user input and using POST for state changes are non-negotiable security basics.
Summary
With the pitfalls and best practices consolidated, you have everything needed to write clean, secure, maintainable JSP. The final lesson puts it all into practice with one complete, real-world project: a student registration application built with servlets, JSP, and sessions.