Tutorials : : A very simple JSP-architecture Part 2

A very simple JSP-architecture Part 2

by Keld H. Hansen

In my last article the architecture and code for a simple "customer-lookup" application was presented. The main idea was to build on the MVC-architecture and to implement this using only JSP-pages and JavaBeans. Furthermore each window of the application should be handled by a controller/view-pair of JSP-pages, where the controller was always invoked with a "command", that told the controller which function to handle.

In the current article I'll show how simple it is to add a couple of new functions to this page, but inspired by a few flaws in the code presented in the first article I'll also discuss briefly the important topic "portability of JSP-pages". Also, while we're into the application error arena, I'll give a few tips on how to ease debugging JSP-pages.

Are JSP-pages portable?

Since Java is designed to be a portable language (you know--"Write once, run anywhere") you might think that JSP-pages are also portable. Since a JSP-page eventually is being translated into a servlet, which is Java class-file, it will be just as easy to port it to other computers and operating system as any other class file. But the conversion from a JSP-file to a servlet may be handled somewhat differently by today's servlet engines. I tested my code on an older version of JRun, and after the article was published I had the opportunity to test the code against two other servlet engines: WebSphere and SUN's JSWDK. This revealed two flaws in my code:

• a Java-comment after an include directive (in ctrlcustomerinfo.jsp) is for some reason allowed by JRun, but the other engines interprets it as HTML. Which is perfectly understandable, since the comment is outside the Java code.
• the error page uses classes from java.io, which JRun automatically imports, but the two other servers do not. You should therefore add this to the top of the error page:

  	    	<%@ page import="java.io.*" %>

I have observed minor differences like this many times before when working with the JSP-technology, and even if the two actual cases are rather simple to debug and correct, you should always be prepared to do modifications in a JSP-application when moving to another servlet engine. 

By the way, you may have wondered why I do not use upper case letters in filenames--for example ctrlCustomerInfo.jsp--to make them more readable. The reason is that servlet engines--like the Java language itself--are case-sensitive. But when writing an URL in the browser's address field you normally prefer to write in lower case letters and most users do not expect an URL to be case sensitive.

Debugging JSP-pages

The major problem with using JSP-pages in a web-application is actually how to locate some of the syntax errors that always will occur when you're coding--no matter how hard you try to avoid them. Below I'll give you a few tips to make life easier for you.

1. Write some small test JSP-pages where you deliberately make syntax errors. Now look at the reaction of the servlet engine. Note that most of the errors are reasonably well diagnosed, but some of them result in absolutely useless error messages. Take your time to experiment, and learn your servlet engine's behavior.

   The reason for the poor error messages, is that they relate to the servlet that has been generated. Line numbers for example will therefore point to the servlet code, not to your JSP-code.

   Here are a couple of test cases to try which will challenge most engines:
   - omit the ending quote of a text
   - omit an ending curly parenthesis
   - omit an ending "%>"

2. Use editors that can color-code the elements of your JSP-pages. With this feature enabled an unfinished text string, for example, will show clearly. 

3. Test your pages often while you are coding them. Don't code more than 10 lines before you test them. If you do this and suddenly get an error in your page, and you can not spot the error right away, you simply remove the new statements one by one (by using your editors "Undo" tool if available) until the error disappears.

4. If an error is really nasty to find, then you might look into the servlet code that has been generated by the servlet engine. If you have a line number to look for you might be able to find the error.