WebSphere Development Studio Client (WDSC) offers a variety of tools to help developers easily debug applications in many environments:
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:
[TABLE]
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:
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:
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 App
To continue reading for free, register below or login
To read more you must become a member of Search400.com
lication 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:
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:
Figure 1 shows how to launch your application in debug mode AFTER starting the test server in debug mode.
[TABLE]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.
[TABLE]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.
[TABLE]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:
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:
Figure 4 shows the JSP stack trace from a compile error that points to the generated servlet source line in error.
[TABLE]Figure 5 shows the generated servlet source line in error with the comment pointing to the matching JSP lines.
[TABLE]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: Jim Mason, president of ebt-now, is an iSeries WebSphere architect, trainer and developer. ebt-now provides iSeries WebSphere, WebFacing engineering, development and training services. You can reach Jim at jemason@ebt-now.com.
