Debug Web applications easily with WDSC

WDSC has a variety of tools to help you easily debug apps in many environments.

WebSphere Development Studio Client (WDSC) offers a variety of tools to help developers easily debug applications

in many environments:

  • iSeries host applications, including ILE, OPM and Java programs.
  • Compiled language debugger for Java running in the WDSC workbench.
  • IBM Distributed Debugger for any application environment, including the built-in WebSphere Test Environment as well as outside JVMs running in Tomcat.

If you're new to Web development with WDSC, this article can help make your experience testing and debugging web applications easier.

WDSC provides many advantages for new Web developers to test and debug Web applications:


Jim Mason

  • Java editor dynamically compiles and checks your Java code during editing, eliminating many errors.
  • Page Designer editor for Java Server Pages (JSPs) dynamically compiles and checks your JSPs during editing, eliminating many errors.
  • Running a Web application with one click eliminates the need for developers to learn WebSphere administration.
  • Java debug support allows easy navigation of code, lets you view and change variable values, and lets you view and change method source code on the fly.
  • Breakpoints can be added or removed from Java classes and Java Server Pages visually in editors.
  • The WDSC JSP compiler makes it easy to trace a Java runtime error in a JSP servlet to the matching source lines in the JSP that created the error.
  • Where needed, Java execution can be traced.

Developers NOT using WDSC to debug and test Java Web applications are often either extremely advanced or in trouble.

JPDA provides Java platform runtime debug support

Sun designed the Java platform to support remote debugging of applications running in the Java Virtual Machine (JVM). A Java API, Java Platform Debug Architecture (JPDA), specifies three debug interface levels for a debug tool or application to debug a JVM.

The Debug support includes three APIs (from easiest to hardest) to implement:

  • JDI (Java Debug Interface)
    Your application uses the JDI agent to access debug functions.
    Sun provides a default command line JDI interface in a JDK.
  • JDWP (Java Debug Wire Protocol)
    Your application accesses the Java Debug service message interface.
  • JVMPI (Java Virtual Machine Platform Interface)
    You write a debug monitor that meets the JVM debug interface specification.

The IBM Distributed Debugger can attach to a JVM IF the JVM is started in debug mode. Since WebSphere and Tomcat run on JVMs, they can be debugged remotely by the IBM tools when started in debug mode.

IBM's WDSC leverages the JPDA architecture and the IBM Distributed Debugger tool to make debugging any application in any environment an easy task.

WDSC Eclipse workbench debugs regular Java apps

The basic Eclipse platform provides an excellent debug tool for Java applications running in the Eclipse workbench. Using the tool, you can set breakpoints, view and change variable values and change code in Java applications from the debugger. It also gives you "standard" debug navigation through your code:

  • Resume -- continue running the application. Resume will run to the end of execution for the entire application IF another breakpoint isn't found.
  • Step into -- step "into" the next lower level method call and debug
  • Step over -- don't step into the next method, just call it and then halt before the next statement in THIS method
  • Go to end -- run to the end of execution for THIS method only

The WebSphere Test Environment makes Web testing easy

With the built-in WebSphere test environment, you can run and test any Web application easily with one click of a button. No, this ISN'T IBM marketing hype. It's REALLY true! While the real WebSphere Application Server HAS become easier to administer in version 5, it's still challenging for most people to learn how to configure and manage applications in WebSphere well. IF you have experience with an earlier version of WebSphere, you won't believe how easy the WDSC WebSphere Test Environment is.

After you have created a Web application, just select the main page to launch the application (often index.html), right click to get the object menu, and select "Run on Server". That's it! WDSC then AUTOMATICALLY does the following:

  • Creates a WebSphere Test server configuration
  • Creates a WebSphere Test Server instance
  • Publishes your application to the test server instance
  • Starts the test server running
  • Loads your application
  • Opens a Web browser in the edit area of the WDSC workbench
  • Loads your first Web page into the browser

For most developers creating Web applications that may be ALL you'll ever need to know about WebSphere administration.

Our company, ebt-now, specializes in building Web applications for iSeries customers and training their developers with custom workshops on WDSC. We use the WebSphere Test Environment extensively. With a Web application running in the test environment, we can connect to back-end iSeries servers (ours or the customer's) over the Web. We then provide our customer with a URL to access their application IN our test server. Users can then run and test the Web application easily WITHOUT having to install WebSphere Application Server, Tomcat or any other J2EE server.

Debugging in the WebSphere Test Environment is simple

IF you have a runtime error testing your application, you can debug it easily with the WebSphere Test Environment.

Setup to debug a Web application

To debug a Web application, just do the following:

  • Add or remove breakpoints in any selected Java classes using the key combination "CTL-SHIFT-B" in the Java editor at any source line.
  • Add or remove breakpoints in any selected JSPs by double clicking in the left margin next to a source statement in the Page Designer editor source view.
  • Publish your Web project to a test server from the Servers view in the Web perspective.
  • Start your WebSphere test server in debug mode from the Servers view in the Web perspective.
  • Select your application's initial Web page in the project navigator view, and click "Run on Server."

Figure 1 shows how to launch your application in debug mode AFTER starting the test server in debug mode.

Figure 1

Running in debug mode

Once your initial page is loaded in the WDSC test Web browser in the workbench, run your application normally.

When your application runs a Java class with breakpoints set, the debug perspective opens and you can see the method source that is executed at that point. You can change variable values or the code.

When your application runs a JSP or servlet, a pop-up dialog asks you if you 1) want to "STEP INTO" this JSP or servlet and execute it line by line OR 2) "SKIP OVER" this JSP. In "STEP INTO" mode, you execute each line of the JSP or servlet as it is highlighted in the debug browser. In "SKIP OVER" mode, the JSP or servlet just runs without stopping unless a breakpoint is reached.

You also have the option to disable "Step by Step" mode on the "Step by Step Debug" dialog. If you disable it, the application will stop only when it encounters breakpoints you've set in a JSP or Java class. If you're interested in only a specific error, this saves time, since you set only one breakpoint and go right to the portion of the application without debugging other items first.

"STEP INTO" mode is useful when you are trying to understand how the Web application works. Again, "SKIP OVER" mode is useful when you are focusing on one specific spot in your application with a breakpoint set.

Figure 2 shows the pop-up dialog for "Step by Step" mode on a JSP service method.

Figure 2

Figure 3 shows the source in the WDSC debug view for a JSP. The top left pane has the execution stack. The top right pane displays the variable values for the current method. The bottom pane shows the JSP source code for the currently executing JSP.

Figure 3

Save the Java source when a JSP is compiled to a servlet

Normally, JSP compilers will read JSP source files and generate Java servlet classes that are executed in your Web application at runtime WITHOUT saving the Java source for the generated servlet class. That makes it difficult at times to link a typical stack trace on a servlet from a runtime error to the matching JSP code that created the problem. You can save the Java source that is generated from a servlet in the WebSphere Test Environment by modifying an IBM configuration file in your Web project. (In the WEB-INF folder look for file: ibm-web-ext.xmi.) Then publish your application to your specific test WebSphere server instance.

The code below shows the changes I made to the ibm-web-ext.xmi file to save the generated Java servlet source for an application:

<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmi:id="WebAppExtension_1"
  reloadInterval="3"
  reloadingEnabled="true"
  additionalClassPath=""
  fileServingEnabled="true"
  directoryBrowsingEnabled="false"
  serveServletsByClassnameEnabled="true">
<jspAttributes xmi:id="JSPAttribute_1" name="keepgenerated" value="true"/>  
              <webApp href="WEB-INF/web.xml#WebApp"/>
<jspAttributes xmi:id="JSPAttribute_2" name="scratchdir" value="C:tempdebug"/>    
              <webApp href="WEB-INF/web.xml#WebApp"/> 
</webappext:WebAppExtension>

I specified a true value for the "keepgenerated" parameter, and I set the "scratchdir" value to "c:tempdebug".

Use the stack trace information to locate a problem in a JSP

Often the stack trace has enough detail to make it clear where the actual problem is in your JSP. If it doesn't, you can trace the cause of the problem to the JSP by doing the following:

  • Locate the servlet service method call near the top of the stack trace. It will usually have a Java source line number for the error if you've saved the Java source.
  • In the work folder you specified for the saved servlet source code, open the Java source with CODE editor. (It has line numbers automatically generated for your source.)
  • Locate the line number from the stack trace in the Java servlet source file. That is the Java code that executed and failed. Above it is a comment line from the WDSC JSP compiler showing the MATCHING JSP source lines that generated this Java code.
  • In WDSC, open you're JSP in Page Designer. Use "CTL-L" to go to the specific line number referenced in the Java servlet source. This is the area where your error occurred in the JSP.

Figure 4 shows the JSP stack trace from a compile error that points to the generated servlet source line in error.

Figure 4

Figure 5 shows the generated servlet source line in error with the comment pointing to the matching JSP lines.

Figure 5

Other debugging tips

Some other items you might be interested in using in a Java web debug scenario include the following:

ebt-now JspLogger
In our WDSC workshops, we provide a EVP.jar file (ebt-now Visual Parts) that contains a Java class (JspLogger) that can easily list selected request, session or application attribute values to the System console. This can reduce the need to run traces to find problems. If you have a skilled Java developer in-house, you can write the same reusable test class.

IBM Distributed Debugger can debug ANY Java environment
The Distributed Debugger is a VERY powerful tool buried in WDSC WebSphere Test Environment wizards. You can run the tool in standalone mode to debug Java Web applications running in environments outside of WDSC: Tomcat, WebSphere, etc. The Distributed Debugger can launch Java applications OR attach to running Java applications on a port (such as a Web application server). The only negative is the Distributed Debugger requires a higher level of Java skill to run.

More information on WDSC web development and debugging

If you're an iSeries RPG developer, another option is the WDSC self-study course I'm writing. It fits scenarios in which you won't have the time or money to become a Java expert BEFORE building e-business applications with WDSC. The VDM approach in that course teaches you how to visually build e-business applications WITHOUT needing to become a Java expert. The "hands-on" labs teach you how to build all types of WDSC applications using WDSC visually using Page Designer and JSP tag libraries. Rochester Initiative will publish this course later this spring.

---------------------------------------

About the author: ebt-now jemason@ebt-now.com
Jim Mason, president of , is an iSeries WebSphere architect, trainer and developer. ebt-now provides iSeries WebSphere, WebFacing engineering, development and training services. You can reach Jim at .
This was first published in March 2004

Dig deeper on Web Tools

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchEnterpriseLinux

SearchDataCenter

Close