Servlets

The servlet application is viewable when you have the sevlet server (in this case Resin), running, have set up the RHCShop ODBC connection to Shop.mdb, and have built and installed the application at Basic_Server. Note that we are using the loopback web address to view the web application: you must have Resin running on the physical machine you run the browser on for this to work. Obviously, you cannot run two different instances of Resin on the same machine as they would clash on port numbers. You can, of course, run the servlet server on any machine and change the web address to point at that machine. However, as we'll see, when developing servlets, you need the ability to start and stop the server easily so I strongly recommend developing with your own personal server instance.

Source code for the sample servlet, stored in the source directory structure described above, is here.

Looking first at the DateTime servlet, we see the basic structure of a servlet: To get a working servlet the only code we really need to provide is the derivation from HttpServlet and a doGet method (note that the API documention for servlets is in the J2EE installation and not the J2sdk). Try running it and refreshing the browser page multiple times.

public final class DateTimeServlet extends HttpServlet
{
	public void doGet(HttpServletRequest request, HttpServletResponse response)
		throws IOException, ServletException
	{
		PrintWriter writer = response.getWriter();
		response.setContentType("text/html");

	writer.println();
	writer.println("<head>");
	writer.println();
	writer.println("</head>");
	writer.println();
	writer.println("<table border=\"0\">");
//  ... many more writer.println statements

	writer.println("<p>");
	long millisecs = System.currentTimeMillis() ;
	Timestamp ts = new java.sql.Timestamp(millisecs) ;
	writer.println("The date and time is now: " + ts);
	writer.println("</p>");
	writer.println("</body>");
	writer.println("</html>");
    }
}

8. Java Server Pages

Servlets often have to generate a great deal of HTML output to include in the response. This means that the servlet code often contains a little bit of program logic and a large number of output statements that, having to produce HTML, have to encode the HTML with lots of escaping characters. This makes it unpleasant to do the page design work necessary and means that the artistic designers have to either work on Java code themselves or have to request change to the code by the Java programmers.

Java Server Pages (or JSP) is an attempt to overcome this problem. Rather than embedding HTML output statements in Java code, JSPs embed Java statements in HTML code. The first time a servlet server is asked to load a JSP page, it automatically "inverts" the JSP page, translating it into a standard servlet with embedded HTML output statements and all the necessary escaping of characters required. It then compiles the resulting servlet and serves it as if it were a normal servlet.

This means that now the artistic designers can work on the presentation of the web pages directly, using standard web page editting tools, while the Java programmers only need to embed their logic in the JSP.

While this has many advantages, it has disadvantages as well: cluttering up the html page with Java tags can mean that the artistic designers can make changes that damage the program logic without realising it. A whole host of technologies have been developed to assist here (e.g. Tag libraries, Bean libraries, Web Macros, Templates etc.) by minimising the amount of Java code necessary in a JSP page or putting a layer of protection in so that it becomes difficult to break the embedded Java code. However no single technology in this area has yet become the accepted best practice approach. In this course we will concentrate on Servlets as, even if you wish to use JSPs, you still need a basic mastery with Servlets before moving on to JSPs.

The sample web application provides an example of a JSP page that prints out the Customers from the Shop database.

9. Handling Request Parameters

The two servlets above have not taken any input from the user other than the request for a response. The FindCustomers servlet handles a text input parameter from a form in the query HTML page, and uses it in a "LIKE" condition of an SQL query to find the customers whose last names begin with the string that was input. Getting a parameter is easy given the support provided by the HttpServlet and HttpServletRequest classes:

String prefix = request.getParameter("prefix") ;
writer.println("<p>Prefix specified was: " + prefix + "</p>") ;

9.1. Problems

Warning

Actually, here I have oversimplified a significant problem (and ignored it completely previously as well): The user could have entered any string at all to the browser. If we simply echo it, as we do above, then it could break the page display if it contained characters like '<', or even full HTML tags. The problem is actually worse: The table cells being output are essentially being dumped into the HTML response page with lines like:

while (rs.next())
{
    writer.println("<tr>") ;
    for (int i = 1 ; i <= colCount ; i++)
    {
		writer.println("<td>" + rs.getObject(i) + "</td>") ;
    }
    writer.println("</tr>") ;
}

What if one of the fields in the database had been entered with a '<' or with something that happened to be a html tag?

For this reason, all output to a web page that comes from a source that is not explicitly coded by the servlet programmer should first pass through a filter that sanitises the text for HTML display. There are a number of such class libraries available free or it is easy to write your own.

Warning

There is a further related problem: in the section where I put the string prefix into the SQL query, I made no check or transformation on the string:

rs = stmt.executeQuery("SELECT * FROM Customers WHERE CustomerLastName LIKE '" + prefix + "%'") ;

Here again problems could occur innocently (e.g. the user enters the string "D'Arc") or less innocently (can you come up with a scenario where some string that the user enters could modify the query in such a way that the resulting query actually causes the database to be modified?). The solution is to program much more careful control over what happens to strings before they are appended to queries for execution.

9.2. Get requests

So far we have handled POST requests. We need to handle GET requests as well. This is simple: there is a doGet method that looks exactly like the doPost. Further the parameters are handled with the same interfaces. Therefore the following bit of boilerplate code will sort out the GET requests:

public void doGet(HttpServletRequest request, HttpServletResponse response)
	throws IOException, ServletException
{
	doPost(request, response) ;
}

9.3. Accessing files from a servlet

A servlet is just a class, or a set of classes, loaded by the servlet server. They are (usually) not processes in their own right but run in a servlet server process (srun, in the case of Resin). This means that the current working directory of the process the servlet is running in may be outside the control of the servlet. Furthermore, this directory may not be predictable before the servlet starts running. Thus static relative pathnames should not be used in a servlet. One could use absolute pathnames but this causes maintenance problems. Instead you can use the following mechanism to turn a pathname relative to the root of the installed web application root into an absolute pathname:

ServletContext app = getServletContext();
String path = app.getRealPath("/WEB-INF/Database.Properties");
FileInputStream in = new FileInputStream(path) ;