HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Java-based technologies such as servlet and JavaServer Pages enable the effective development of component-based, server-side Web applications. Although servlets can be self-contained programs, it's more common that JavaBeans handle the business logic, JSP components handle the presentation logic and servlets handle the HTTP protocol interaction flows.

Servlet and JSP components should be tested individually to ensure that they conform to the functional specifications. More important, they should be tested after they've been integrated to form a server-side Web application. This article describes the development scenario for a typical server-side Web application and outlines the advantages of interactive debugging and iterative unit testing. It then demonstrates how debugging and unit testing can be accomplished using the IBM VisualAge for Java software development product.

Typical Server-Side Web Application Scenario
Our sample scenario involves the development of a Web-based employee telephone directory for a fictitious company, Acme Inc. Using a Web browser, employees can look up information on another employee by name, department number and so on. The application performs the search based on the input criteria and presents the results on a new Web page. Figure 1 depicts the application flow and architecture.

Figure 1
Figure 1:

Our Web application uses a typical three-tier architecture. An HTML-based client user interface is served by a Web server and hosted inside a Web browser running on the end user's computer. Java, servlet and JSP code is executed on an application server, while a data access request is delegated to a database server. A simple HTML file, PhoneBookInput.html, is used as the search criteria input page. When the user pushes the Search button, the request is passed to a servlet, PhoneBookServlet, for processing. This servlet uses JavaBeans to perform the lookup in a DB2 database via the appropriate JDBC calls and stores the found information in a JavaBean called Employees. The PhoneBookOutput.jsp file is then called from the servlet. This JSP file extracts information from the Employees bean in order to present the search results.

Need for Debugging and Unit Testing
Debugging and unit testing are part of an iterative development cycle in the software engineering process. The interpretive and dynamic nature of HTML and Java make the two tasks critical.

Servlets can be executed with the help of servletrunner, a utility available in the Java Servlet Development Kit (JSDK). Often, to test out a particular function in a servlet, we need to involve the associated input and output HTML and JSP components. Combined with the limitations of servletrunner, this approach is neither practical nor effective for rapid application development. A more common approach is to test servlets using a Web server with a servlet engine plug-in.

To meet the requirements of testing JSP files, we need a JSP processor so that JSP files are first page-compiled into servlets, then executed. You've probably encountered a typical setup for servlet/JSP development: a standard Java IDE and an external Web server with servlet/JSP support. It's more productive, however, to have a RAD environment with built-in support for interactive debugging and iterative unit testing of both servlets and JSP code.

To perform the debugging and unit-testing tasks effectively, we need the ability to (1) trace both our Java and our JSP code, (2) examine the application execution information, (3) make some changes to the code and (4) continue with the current execution without restarting from the beginning.

Debugging and Unit Testing with VisualAge for Java
The Professional and Enterprise editions of VisualAge for Java, version 3.02, incorporate the WebSphere Test Environment (WTE) in the IDE so you can easily debug and unit-test servlets and JSP codes. The IDE includes an interactive debugger and supports incremental compilation. Servlets are tested using a Web browser that sends a request to the servlets executing in the IDE. You can set breakpoints in the servlet, debug it and make code modifications that are dynamically linked to the running code.

To launch the WTE, invoke the cascading menu item "Workspace | Tools | Launch WebSphere Test Environment" from the IDE Workbench window. This starts the built-in WTE Web server and the associated servlet engine. Behind the scenes, this menu item runs the com.ibm.servlet.SERunner class with predefined properties. To test JSP code and servlets, invoke your favorite Web browser with the appropriate URL. For our sample application we point our browser to http://localhost:8080/PhoneBook/PhoneBookInput.html, which displays our search criteria input page. After we've pressed the Search button to submit the request, our PhoneBookServlet is invoked. Finally, our PhoneBookOutput.jsp is called to present the search results. Figure 2 illustrates the flow of program execution.

Figure 2
Figure 2:

JSP code is supported by the WTE, which compiles a JSP file into a servlet and runs it. Compilation occurs the first time the JSP file is requested and whenever the JSP file changes. A JSP Execution Monitor allows you to step through JSP code and debug its corresponding generated servlet code, which is automatically imported into the IDE. Given this functionality, you can seamlessly trace and debug the JSP code and all the scriptlets and JavaBeans used by it. To configure the JSP Execution Monitor, invoke the cascading menu item "Workspace | Tools | JSP Execution Monitor...", which displays a dialog box with the various options available. Once you've enabled the IDE to monitor JSP code execution, the JSP Execution Monitor window will be launched whenever a JSP file is called. As Figure 3 shows, you can trace the execution of the JSP file at source-code level, and you can watch the corresponding generated servlet Java code as well.

Figure 3
Figure 3:

To debug the generated servlet code, you need to set breakpoints in the servlet, which has been automatically imported into the JSP Page Compile Generated Code project inside the IDE after successful JSP page compilation. From there you simply run and debug the servlet as you would for any other Java code in the IDE.

Incremental Compilation and Hot Linking
In other programming environments, after you've made code changes to your servlet, JSP code or JavaBeans used by the JSP file, you have to stop and restart the Web server to update and reload the corresponding Java classes. During your daily RAD, source modification is a typical, routine coding activity. Having to stop and restart the Web server and plug-ins can be frustrating, and can significantly slow down the edit/test/debug development cycle.

VisualAge for Java supports incremental compilation and hot-linking. When you make changes to a method in a Java class, only that method gets recompiled. In the IDE you can modify code in the debugger and continue to run with the new code without exiting or restarting the debugger. You can reset to a specific stack frame and resume running from there without having to reload the entire Java class and start from the beginning. In addition, you can run code that has errors in other parts of your Java class. In addition to hot linking and debugging interactively, you can start testing and fixing up "placeholder" code on the fly, even if the entire Java class isn't syntactically correct and hasn't been compiled completely in advance.

Figure 4 shows the debugger that's built into the VisualAge for Java IDE. We use the debugger to step into the Employees JavaBean, which is used by the JSP file that we're tracing in the JSP Execution Monitor. In the debugger window you can view the program execution stack, inspect the value of variables, modify the code and save the changes in the source view pane, and so on.

Figure 4
Figure 4:

These features in the IDE provide a great boost to your productivity. Changes to your JSP code can be reloaded into the WTE, which automatically retranslates the new JSP code into a servlet. After the page compilation, you can resume debugging and unit testing with the modified code without stopping and restarting the Web browser or the WTE Web server and servlet engine. This shortens the edit/test/debug cycle and enables you to discover and debug subtle programming errors, such as bugs that would occur only after your servlets and JSP files have been running for a long time.

Conclusion
In developing server-side Web applications, it's imperative that you be able to debug and unit-test servlets and JSP files both individually and together. The incremental compilation and hot-linking features in VisualAge for Java, combined with the built-in unit test environment and JSP Execution Monitor, increase your programming productivity and make it easier for you to interactively debug and iteratively unit-test your server-side Web applications.

Author Bio
Jin Li, a software designer at the IBM Toronto Laboratory, is currently working on VisualAge for Java and WebSphere solutions. He holds an MS in computer science from the University of Toronto and is a member of ACM and the Toronto Java User Group. Jin can be contact at: [email protected]

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.