• Post Reply Bookmark Topic Watch Topic
  • New Topic

Making servlet listening on JSP pages  RSS feed

Sergei Zhylinski
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI Everyone,

I know that the default welcome file list in the deployment descriptor includes not only index.htm(l) but index.jsp too. A user can create servlet mapping manually to make a servlet catch requests targeted to JSP pages too:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:web="http://xmlns.jcp.org/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd http://xmlns.jcp.org/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"


I wonder whether it is userful. JSP is a servlet as well. When a request comes to a JSP page a container generates code and stores it somewhere (particularly, Tomcat puts it into $CATALINA_HOME\work directory). So when a mapping exists that makes a servlet catch JSP page requests, the container will not generate code for a JSP page and will not run it. Could someone please suggest when it is appropriate to create such mappings?
Bear Bibeault
Author and ninkuma
Posts: 66154
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I personally believe that it never is. JSPs should be used for views only, and should have page controller servlets that do any work required in order to show the page; such as fetching the data to be displayed. Forms and such should also be submitted to task controller servlets and not JSPs which are not units of processing, but units of view.

In this scenario, JSPs are never directly addressed by URL and hence need no mappings.

This is all described in detail in this article.
Tim Holloway
Posts: 18662
Android Eclipse IDE Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Tomcat, URLs that do not have a mapping in web.xml are routed to a "default servlet" that is built into the Tomcat server itself. Other J(2)EE containers might do it differently, though.

The default servlet analyzes the incoming URL and attempts to resolve it to a resource path in the webapp's WAR. If if finds a simple file resource, it opens that resource and copies it out to the response stream. If it finds a directory resource, it constructs an HTML page that contains a directory listing. If it cannot find the resource at all, it generates a "404 - Resource not found" error page - or, if web.xml defines a custom 404 page, it will use that definition.

And if the resource URL ends with JSP, a check is made to see if a class with the corresponding name exists, and if not, it attempts to locate the corresponding JSP resource, which it will then route to the Jasper JSP-to-Java translator, and then to the javac compiler (or some equivalent) to create the class. The exact locations of the interim Java and class files is known, but shouldn't be exploited, since they're not defined to the J2EE standard and may change location, format, and use in other versions of Tomcat or non-Tomcat J(2)EE servers.

Note also that the login and loginfail pages as well as several other resources defined in web.xml but presented by Tomcat may be JSPs. A similar mechanism applies there, even though there are no explicit URLs associated with those resources (for example, attempting to make an explicit request to a login JSP will not function properly, because only Tomcat internal security requests can set up the required context).

But whether you agree with Bear's Rule that JSPs should NEVER be explicitly requested or not, it's still not a good idea to meddle with the standard behavior, so leave the "*.jsp" route out of your web.xml.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!