Servlets Debugging

It is constantly hard to testing/debugging a servlets. Servlets will in general include a lot of client/server collaboration, making blunders likely yet hard to reproduce.

Here are a couple of insights and recommendations that may help you in your debugging.


System.out.println() is anything but difficult to use as a marker to test whether a specific bit of code is being executed or not. We can print out factor variable too. Moreover −

  • Since the System object is a piece of the center Java objects, it tends to be utilized wherever without the need to introduce any additional classes. This incorporates Servlets, JSP, RMI, EJB's, standard Beans and classes, and standalone applications.

  • Stopping at breakpoints system stops the typical execution subsequently takes additional time. While writing to System.out doesn't meddle much with the ordinary execution stream of the application, which makes it truly important when timing is crucial.

Following is the linguistic structure to utilize System.out.println() −

System.out.println("Debugging message");

All the messages created by above language structure would be signed in web server log file.

Message Logging

It is constantly incredible plan to utilize legitimate logging strategy to log all the troubleshoot, cautioning and mistake messages utilizing a standard logging technique. I use log4J to log all the messages.

The Servlet API likewise gives a straightforward method for yielding data by utilizing the log() technique as pursues −

//Import required java libraries 


import javax.servlet.*; 

import javax.servlet.http.*; 

public class ContextLog extends HttpServlet { 

public void doGet(HttpServletRequest request, HttpServletResponse response) 

throws ServletException, { 

String standard = request.getParameter("par1"); 

//Call the two ServletContext.log methods 

ServletContext setting = getServletContext( ); 

if (par == null || par.equals("")) 

//log form with Throwable parameter 

context.log("No message received:", new IllegalStateException("Missing parameter")); 


context.log("Here is the guest's message: " + par); 

response.setContentType("text/html"); out = response.getWriter( ); 

String title = "Context Log"; 

String docType = 

"<!doctype html open \"-/w3c//dtd html 4.0 " + "transitional//en\">\n"; 

out.println(docType + 

"<html>\n" + 

"<head><title>" + title + "</title></head>\n" + 

"<body bgcolor = \"#f0f0f0\">\n" + 

"<h1 adjust = \"center\">" + title + "</h1>\n" + 

"<h2 adjust = \"center\">Messages sent</h2>\n" + 




} //doGet 


The ServletContext logs its instant messages to the servlet holder's log document. With Tomcat these logs are found in <Tomcat-establishment directory>/logs.

The log documents do give a sign of new developing bugs or the recurrence of issues. Therefore it's great to utilize the log() work in the catch proviso of exemptions which ought to regularly not occur.

Using JDB Debugger

You can debug servlets with the same jdb commands you use to troubleshoot an applet or an application.

To debug a servlet, we troubleshoot sun.servlet.http.HttpServer and cautiously watch as HttpServer executes servlets in light of HTTP asks for produced using program. This is fundamentally the same as how applets are repaired. The thing that matters is that with applets, the real browser being fixed is sun.applet.AppletViewer.

Most debuggers conceal this detail via consequently realizing how to troubleshoot applets. Until they do likewise for servlets, you need to help your debugger by doing the accompanying −

  • Set your debugger's classpath so it can discover sun.servlet.http.Http-Server and related classes.

  • Set your debugger's classpath with the goal that it can likewise discover your servlets and bolster classes, normally server_root/servlets and server_root/classes.

You regularly wouldn't need server_root/servlets in your classpath in light of the fact that it incapacitates servlet reloading. This incorporation, be that as it may, is valuable for debugging . It enables your debugger to set breakpoints in a servlet before the custom servlet loader in HttpServer loads the servlet.

Once you have set the best possible classpath, begin debugging sun.servlet.http.HttpServer. You can set breakpoints in whatever servlet you're keen on debugging , at that point utilize an internet browser to make a demand to the HttpServer for the given servlet (http://localhost:8080/servlet/ServletToDebug). You should see execution being ceased at your breakpoints.

Using Comments

Comments in your code can enable the debugging to process in different ways. commands can be utilized from multiple points of view in the debugging process.

The Servlet utilizes Java commands and single line (//...) and various line (/* ... */) commands can be utilized to briefly expel portions of your Java code. On the off chance that the bug vanishes, debug the code you just remarked and discover the problem.

Client and Server Headers

Sometimes when a servlet doesn't carry on not surprisingly, it's helpful to take a look at the raw HTTP ask for and reaction. In case you're acquainted with the structure of HTTP, you can peruse the demand and reaction and see precisely what precisely is running with those headers.

Important Debugging Tips

Here is a rundown of some all the more investigating tips on servlet debugging −

  • Remember that server_root/classes doesn't reload and that server_root/servlets most likely does.

  • Ask a browser to demonstrate the raw substance of the page it is showing. This can help recognize arranging issues. It's typically an alternative under the View menu.

  • Make beyond any doubt the browser isn't reserving a past demand's yield by compelling a full reload of the page. With Netscape Navigator, use Shift-Reload; with Internet Explorer use Shift-Refresh.

  • Verify that your servlet's init() strategy takes a ServletConfig parameter and calls super.init(config) immediately.

© Javacodegeeks 2018 -
All Right Reserved and you agree to have read and accepted our term and condition.

Python 3