One of the most difficult components of building servlets is testing and debugging. Because servlets include a lot of client/server interaction, they’re prone to errors–though they’re hard to come by. Because servlets operate inside a strongly multithreaded and typically complicated web server, they don’t function well with ordinary debuggers, it might be difficult to track down the reason for nonobvious failures.
You may also utilize your server’s interactive display to debug a servlet by following these steps:
- To build your servlet, use the javac -g command in the Qshell Interpreter.
- Place the source code (.java file) and compiled code (.class file) in a classpath directory.
- Launch the server.
- On the job where the servlet runs, perform the Start Service Job (STRSRVJOB) command.
- STRDBG CLASS(myServlet), where myServlet is your servlet’s name. It is necessary to show the source.
- Press F12 to set a breakpoint in the servlet.
- To update the modifications, click the Refresh button in the Web Browser if automatic class reloading is enabled, which is the default configuration. The state of your application is not lost.
- You lose the state of the program if automatic class reloading is not enabled. Restart the server to apply the modifications.
Few hints and suggestions that may aid you in your debugging:
- By using System.out.println()
- The message log
- Using JDB Debugger
- Use comments
- Client and Server Headers
Using System.out.println() command
System.out.println() is a marker that is used to see if a given piece of code has been run. The variable’s value can also be printed. Furthermore:\
Because System objects are part of the core Java objects, they may be used everywhere without the requirement for extra classes to be installed. Servlets, JSPs, RMIs, EJBs, Common Beans and Classes, and stand-alone apps are all examples of this.
Write to System with various pauses at the breakpoint. It does not interfere with the application’s usual flow of execution, which means that timing is critical when it is very beneficial.
Syntax: To use System.out.println() command
System.out.println("Debugging message");
All of the messages created by the above syntax will be recorded in the log file of the webserver.
message log
Use the proper logging mechanism to capture all debug, warning, and error messages, which is a great idea; log4J is suggested for capturing all messages. The log () function in the Servlet API also provides an easy way to output:
Example:
Java
// Java Program to Illustrate log4J for Capturing// All Messages Logs// Importing required classesimport java.io.*;import javax.servlet.*;import javax.servlet.http.*;// Class// Extending HttpServlet classpublic class GFG extends HttpServlet { // Method 1 public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { String par = request.getParameter("par1"); // Calling the two ServletContext.log methods ServletContext context = getServletContext(); if (par == null || par.equals("")) // log version with Throwable parameter context.log("No message received:", new IllegalStateException( "Missing parameter")); else context.log("Here is the visitor's message: " + par); response.setContentType("text/html"); java.io.PrintWriter out = response.getWriter(); // Title to be displayed String title = "Geeksforgeeks Context Log program "; String docType = "<!doctype html public \"-//w3c//dtd html 4.0 " + "transitional//en\">\n"; out.println( docType + "<html>\n" + "<head><title>" + title + "</title></head>\n" + "<body bgcolor = \"#f0f0f0\">\n" + "<h1 align = \"center\">" + title + "</h1>\n" + "<h2 align = \"center\">Messages sent successfully </h2>\n" + "</body></html>"); }} |
File: web.xml
XML
<web-app> <servlet> <servlet-name>GFG</servlet-name> <servlet-class>GFG</servlet-class> </servlet> <servlet-mapping> <servlet-name>GFG</servlet-name> <url-pattern>/GFG</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>GFG.java</welcome-file> </welcome-file-list></web-app> |
Output: Run the GFG.java file, you will get the following output:
Using JDB Debugger
To debug Servlet, use the applet or application debugging jdb command.
We may use sun.servlet.http.HttpServer to debug a Servlet and then run it as HttpServer Servlet to answer HTTP requests on the browser side. This simple debugging applet software is similar. The real application being debugged is sun.applet.AppletViewer when debugging an applet.
The details of how to debug an applet are usually hidden by default in most debuggers. Similarly, using the debugger, you must perform the following for the servlet:
- Set the classpath of your debugger so that sun.servlet.http.Http-Server and associated classes may be found.
- Set your debugger’s classpath to find your servlet and accompanying classes, which are normally located at server root/servlets and server root/classes in Server root/servlets should not be in your classpath since it prevents servlet reloading. This inclusion, on the other hand, is beneficial for debugging. It enables your debugger to set breakpoints in a servlet before HttpServer’s proprietary servlet loader loads it.
Start debugging sun.servlet.http.HttpServer after you’ve specified the right classpath. You may use a web browser to make a request to the HttpServer for the supplied servlet (http://localhost:8080/servlet/ServletToDebug) after setting breakpoints in the servlet you want to debug. At your breakpoints, you should observe execution halt.
Using comments
Debugging will be aided by comments in the code in a variety of ways. Notes may be utilized in a variety of ways to aid with the debugging process.
To temporarily delete some Java code, use Java Servlet comments and single-line comments (//…), multi-line comments (/ *… * /). If the bug goes away, all you have to do now is look at the commented code to figure out what’s wrong.
Client and Server Headers
When a servlet fails to operate as intended, it’s sometimes helpful to examine the raw HTTP request and response. If you know how HTTP works, you can read the request and response and figure out exactly what’s going on with the headers.
Note: Do remember certain important keypoints for debugging. Here is a list of some other servlet debugging tips:
- Keep in mind that server root/classes do not reload, although server root/servlets very certainly do.
- Request that a browser displays the raw content of the page it is now viewing. This can aid in the detection of formatting issues. Under the View menu, it’s generally an option.
- By requiring a full refresh of the website, you can ensure that the browser isn’t caching the results of a prior request. Use Shift-Reload in Netscape Navigator and Shift-Refresh in Internet Explorer.
- Check that the init() function of your servlet accepts a ServletConfig argument and immediately calls super.init(config).
