Debugging Servlets

By: aathishankaran Emailed: 1784 times Printed: 2614 times    

Latest comments
By: rohit kumar - how this program is work
By: Kirti - Hi..thx for the hadoop in
By: Spijker - I have altered the code a
By: ali mohammed - why we use the java in ne
By: ali mohammed - why we use the java in ne
By: mizhelle - when I exported the data
By: raul - no output as well, i'm ge
By: Rajesh - thanx very much...
By: Suindu De - Suppose we are executing

Naturally, when you write servlets, you never make mistakes. However, some of your colleagues might make an occasional error, and you can pass this advice on to them. Seriously, though, debugging servlets can be tricky because you don’t execute them directly. Instead, you trigger their execution by means of an HTTP request, and the Web server executes them. This remote execution makes it difficult to insert break points or to read debugging messages and stack traces. So, approaches to servlet debugging differ somewhat from those used in general development. Here are seven general strategies that can make your life easier.  

1. Look at the HTML source.

If the result you see in the browser looks funny, choose “View Source” from the browser’s menu. Sometimes a small HTML error like <TABLE> instead of </TABLE> can prevent much of the page from being viewed. Even better, use a formal HTML valuator on the servlet’s output. See Section 2.5 (Simple HTML-Building Utilities) for a discussion of this approach.

2. Return error pages to the client.

Sometimes certain classes of errors can be anticipated by the servlet. In these cases, the servlet should build descriptive information about the problem and return it to the client in a regular page or by means of the sendError method of HttpServletResponse. See Chapter 6 (Generating the Server Response: HTTP Status Codes) for details on sendError. For example, you should plan for cases when the client forgets some of the required form data and send an error page detailing what was missing. Error pages are not always possible, however. Sometimes something unexpected goes wrong with your servlet, and it simply crashes. The remaining approaches help you in those situations.

3. Start the server from the command line.

Most Web servers execute from a background process, and this process is often automatically started when the system is booted. If you are having trouble with your servlet, you should consider shutting down the server and restarting it from the command line. After this, System.out.println or System.err.println calls can be easily read from the window in which the server was started. When something goes wrong with your servlet, your first task is to discover exactly how far the servlet got before it failed and to gather some information about the key data structures during the time period just before it failed. Simple println statements are surprisingly effective for this purpose. If you are running your servlets on a server that you cannot easily halt and restart, then do your debugging with the JSWDK, Tomcat, or the Java Web Server on your personal machine, and save deployment to the real server for later.

4. Use the log file.

The HttpServlet class has a method called log that lets you write information into a logging file on the server. Reading debugging messages from the log file is a bit less convenient than watching them directly from a window as with the previous approach, but using the log file does not require stopping and restarting the server. There are two variations of this method: one that takes a String, and the other that takes a String and a Throwable (an ancestor class of Exception). The exact location of the log file is server-specific, but it is generally clearly documented or can be found in subdirectories of the server installation directory.

5. Look at the request data separately.

Servlets read data from the HTTP request, construct a response, and send it back to the client. If something in the process goes wrong, you want to discover if it is because the client is sending the wrong data or because the servlet is processing it incorrectly. The EchoServer class, shown in the article (A Debugging Web Server), lets you submit HTML forms and get a result that shows you exactly how the data arrived at the server.

6. Look at the response data separately.

Once you look at the request data separately, you’ll want to do the same for the response data. The WebClient class, presented next in Section 2.10 (WebClient: Talking to Web Servers Interactively), permits you to connect to the server interactively, send custom HTTP request data, and see everything that comes back, HTTP response headers and all.

7. Stop and restart the server.

Most full-blown Web servers that support servlets have a designated location for servlets that are under development. Servlets in this location (e.g., the servlets directory for the Java Web Server) are supposed to be automatically reloaded when their associated class file changes. At times, however, some servers can get confused, especially when your only change is to a lower-level class, not to the top-level servlet class. So, if it appears that changes you make to your servlets are not reflected in the servlet’s behavior, try restarting the server. With the JSWDK and Tomcat, you have to do this every time you make a change, since these mini-servers have no support for automatic servlet reloading.

JSP Home | All JSP Tutorials | Latest JSP Tutorials

Sponsored Links

If this tutorial doesn't answer your question, or you have a specific question, just ask an expert here. Post your question to get a direct answer.

Bookmark and Share


Be the first one to add a comment

Your name (required):

Your email(required, will not be shown to the public):

Your sites URL (optional):

Your comments:

More Tutorials by aathishankaran
Web Security Issues
The Web User's Perspective
Server-side plug-Ins
The best way to avoid security vulnerabilities with new server
JavaScript Security
Window Object
Working with Status Bar Messages
Retrieving a Portion of a String
Referencing Windows
Math Object
Frame Object
Document Object
Closing Windows
Built-in Object in Javascript
Textarea Object

More Tutorials in JSP
LifecycleException: service.getName(): "Catalina"; Protocol handler start failed: ` Permission denied <null>:80
JSP Alert Example
JSP CheckBox Example
Uploading an Image to a Database using JSP
Uploading a file to a server using JSP
A JSP page that gets properties from a bean
The page Directive in JSP
The taglib, tag, include, attribute and the variable Directive in JSP
Declarations in JSP
Scriptlets and Expressions in JSP
Tag Libraries in JSP
The Request Object in JSP
The Response Object in JSP
The Out Object in JSP
The Session Object in JSP

More Latest News
Most Viewed Articles (in JSP )
JSP Example to connect to MS SQL database and retrieve records
What are the different scopes in JSP?
JSP CheckBox Example
JSP Alert Example
Comparison operators in JSP
Sending Email using JSP
Uploading an Image to a Database using JSP
Arithmetic Evaluation Using the Expression Language in JSP
The Advantages of JSP
Writing your first JSP page
Uploading a file to a server using JSP
The Request Object in JSP
Disabling Scriptlets in JSP using web.xml
Deploying an Individual JSP on Tomcat
Automatically Refreshing a JSP
Most Emailed Articles (in JSP)
The Tag Life Cycle with Attributes in JSP
Calling JSP from a batch file
JSP Program for display Date
Sessions in JSP
Simple HTML-Building Utilities
Handling Events
Using a DataSource from WebLogic in a JSP
The JSP Program running first Time.
Declaring variable in JSP
The Advantages of JSP
Password Object
Retrieving a Portion of a String
Automatically Including Preludes and Codas in JSP
The Differences Between Simple and Classic Tags in JSP