 | Level: Intermediate Ahmed Khalifa, Staff Software Engineer, IBM VisualAge and WebSphere Worldwide Enablement Team, IBM Toronto Lab
06 Mar 2002 This article introduces how to use the debugger and some of its basic/integrated features to debug Java applications, using EJBs, servlets, and JSPs inside WebSphere Studio Application Developer.
Introduction In 2001 IBM introduced the Eclipse platform to the Open Source
community in an effort to make the tooling of its products more open to third
party contribution and to enhance the platform in general. As part of this strategy,
IBM now provides a new set of tools to build enterprise JavaTM applications based
on the Eclipse platform. This new set of tools is called WebSphere® Studio Application
Developer which integrates a Java-based debugger as its own debugger. This provides us with a great benefit, as we no longer have
to use two debuggers. VisualAge® for Java consists of an internal debugger to
debug inside VisualAge for Java, and the IBM Remote Debugger to debug remote
servers. Now we can use one debugger that serves all purposes, and is rich with
features that IBM always provided. We are going to introduce this debugger to you in two articles.
We assume that the reader is familiar with the basics of J2EE, WebSphere Studio
Application Developer development and deployment. In this article, we'll introduce you to how to use the debugger
and some of its basic/integrated features to debug Java applications, using
EJBs, Servlets and JSPsTM inside WebSphere Studio Application Developer.
We will take a hands-on approach, introducing a simple Web application that
has nested problems (a problem in the JSP, a problem in the Servlet, and a
problem in the EJB code), and we will use the debugger to discover and fix all
three. In Part
2, we'll explain how to use the WebSphere Studio Application Developer to
debug your application after it has been deployed into the WebSphere Application
Server, Advanced Edition (AE) . The downloadable file below, DebugInWSADpt1.zip,
contains the classes and archives described in this article.
Debugging a simple Java application Launching your Application in the debugger:
- Switch into (or open) a Java perspective
- Create a new Java project and call it TestDebug.
- Import the sample Java application
testdebug.jar
file into the TestDebug project.
- Examine
poc.debug.app.AppDebug.java. It is a simple application
that we'll use to demonstrate the basics of the debugger.
- Insert a breakpoint at the following statement located in the main method
inside the loop:
x = y + z;
You can do that by double clicking on the left pane of the source code or
by using the pop-up menu as shown in Figure 1 below.
Figure 1. Adding breakpoint to source
- In the toolbar click the Debug (
) button. You'll see a dialogue asking you which launcher you want to use.
Choose Java Application, check the Set as default launcher...
check box, and click Next.
The other button to run applications is the Run ( 
) button. This runs the application in a non-debug Java JVM which is faster
for execution, but doesn't allow debugging or using breakpoints. This is a
fundamental difference between WebSphere Studio Application Developer and
VisualAge for Java which ran all applications in its own JVM and was always
in debug mode. Whereas WebSphere Studio Application Developer uses pluggable
JVM's and you get to choose if you want to run in either Debug mode or not.
- Select the class you want to test. WebSphere Studio Application Developer
gives you a choice to select a group of classes in the same project to launch using
the Application Launcher.
- The launcher will launch another JVM process to run your application (a
look at Windows® Task Manager will show an extra
javaw
process, and a Debug view will come up with the AppDebug.java
source code.
Now Lets stop and take a quick look at the different views
and functions we can use in the Debug Mode.
Debugger perspective and Debugger tasks Debug/Process/Navigator view The Debug view displays your current threads, previous terminated
threads, the execution stack and the current breakpoint you are stopped in.
Note that it is the debug view that carries the familiar buttons: Step,
Step into, Step out, Run, Suspend, and other debug
control buttons. Clicking on the Process pane will show you the current process,
which executable (javaw in our case) the system
is using to run this application. The Navigator pane is simply a navigator to allow you to navigate
through the code and maybe set some more breakpoints without leaving the Debug
Perspective.
Figure 2. Debug/Process/Navigator view
Breakpoint/Inspector/Variables/Inspector view The default pane in this view is the Breakpoints view, where
you'll see a list of the available breakpoints in your program. You can also
right-click on a breakpoint and from the pop-up menu select HitCount
which tells the debugger to stop after a certain number of hits. This is useful
for breakpoints inside loops where you want to stop at a certain iteration of
the loop. Set the HitCount on your break point to 2. If you click on the Variable pane, you'll get a chance to
see the available variables, and their values. Right-click on any variable and
you'll get the following options.
- Inspect - The variables view might include a great amount of variables.
The inspector view allows you to focus on the few variables that you interested
in.
- Change Value - This is a very important feature. When you choose
this option you'll be allowed to change the value of the selected variable
and study the effect of this change on your program execution.
- Show Type Names - This option displays the type of the Variable.
- Show Qualified Names - This option allows you to see the fully qualified
name of the variable type.
Figure 3. Breakpoint view
Figure 4. Variables views
Click the Run (  ) button and you'll notice that the execution will stop at the breakpoint. Check
the value of the count variable and other variables to confirm
that it stopped at the second iteration in the loop. This is the hit count we
set earlier.Code, Outline, and Tasks/Console views The Code and outline views are the same views you've seen
in other perspectives. So is the tasks view which shares the same pane with
the Console view. One of the good features about the debugger is the ability
to run to a certain point in the code. For example, if we now want to run and stop the statement
following the loop, we can right-click on that statement in the code view
and select Run to Line. As you step-over that statement the program outputs
the value of x in the console. Notice how the console becomes the active pane
automatically. This is the default behavior of the console, and it becomes active
every time you output something. You can change this behavior and the output
format in the console from the Debug pane in the Preferences dialog. Changing your code while running the debugger (hot changes) In VisualAge for Java we had the feature of "hot method
compiling." This means that we can change code inside a method as we debug
it, and the debugger will bounce to the beginning of the execution block automatically
and we'll continue debugging with no need to re-run our application. This was
a feature that was available for the VisualAge for Java JVM which we call a
"J9" class JVM. This feature is not available in the Standard JVMs
such as the ones shipped with WebSphere Studio Application Developer. The new tooling does allow for the reloading of Servlets inside
WebSphere Application Server when you make changes to this Servlets. This guarantees
that the second execution of this Servlet method will reflect your latest changes.
Debugging of Servlets/JSPs To demonstrate the compiler capabilities of debugging Servlets/JSPs,
load the TestEAR.ear file into a project named TestEAR.
If you get any compilation errors, make sure that the just created AdderEJB
project is in the classpath of the AdderWEB
project. Understanding the Adder Enterprise Application We built a session EJB that is called poc.debug.ejbs.AdderSession
which provides a strCat method that concatenates
two strings using memory buffers (the quick recommended way to concatenate strings
in Java). We also have an access bean around our session bean poc.debug.ejbs.AdderSessionAccessBean. We built Web access to this access bean using WebSphere Studio
Application Developer which generated the following:
poc.debug.Servlet.AdderController - Servlet that directs the input from
the form into the output JSP.poc.debug.Servlet.AdderViewBean - This bean encapsulates the logic which
calls the Access Bean's strCat and then passes the results back
to the caller.AdderInputForm.html - This is the input form that takes user input and calls
the AdderController Servlet.AdderResults.jsp - This is the JSP result page which uses the AdderViewBean
to display the results. Configure/Run the Application
- Create a WebSphere 4.0 Test Instance/Configuration and call it TU
(for Test Unit).
- In the Configuration of TU, right-click and add the TestEAR
EAR to the configuration.
- From the Servers view, select the TU server and click the Run (
) button.
- From your Web browser type: http://localhost:8080/Adder/
- This should automatically load the
AdderInputForm.html
as it is configured as a welcome page.
- In the input form, type any two strings, click Submit and notice
the result.
- You should get a 404 error file not found AddResultX.
Stop the server, and let's find out how to use the debugger
to locate this problem. Debugging the Servlet
- In a Java or a Web perspective open the
AdderWeb
project and locate the AdderController.performTask() method.
- Set a breakpoint at the first line inside the
try block: performServices(request,
response);
- Now start your server again, but this time click the Debug (
) button, so that the server will start in debug mode with breakpoints enabled.
- Reload the
AdderInputForm.html in your Web browser.
- Enter any two strings in the fields in the input form and click Submit.
- You'll notice that the Server perspective becomes active and you'll be able
to debug inside it.
The first thing you'll notice inside the server perspective is that the Debug, Console and Variables panes share the same window! This may be inconvenient since you'll be switching windows every time you need to check a variable value as you step through your code. The remedy to this is to either rearrange the server view yourself, or do your debugging in the Debug view which is better suited for the process. There are two ways to debug in your Debugger perspective. The first easy way to is to switch to the debugger perspective manually before you hit the breakpoint in your code. This is not always easy. Say you have a break point in your HttpServlet.init() method
which is set to load automatically at startup. So we'll show you now how to
debug your server in the Debug perspective, even if you got the breakpoint
in the server or any other perspective.
- Switch to the Debug Perspective.
- In the Debug view, locate the Server process first, as shown in Figure 5
below.
Figure 5. Debug process view
- In the list of the threads running under the server, locate the thread near
the bottom of the list that says Suspended (breakpoint ... next to
it, as shown in Figure 6 below. As in Figure 5 above, locating this thread
should be visually easy since it has the + sign next to it. If you
expand it, you'll see the execution stack.
Figure 6. Suspended process in debug view
- Double-click on the top of the stack, and you'll see the source code in
your Debug perspective.
- Step through your Servlet code. You will see that we set the value of the
variable
nextPage manually to AddResultX.
We should be using the getInitParameters() method instead.
- Comment the following line in your code:
nextPage = "AddResultx";
- Un-comment the following line (which contains the correct code):
//nextPage
= getInitParameter(request.getParameter("command"));
- Save the Servlet.
As mentioned earlier, WebSphere Application Server 4.0 has the ability to
automatically reload Servlets and JSPs so you don't have to restart the server
each time you change your Servlets or JSPs.
- For the sake of this hands-on, it would be easier if you remove/disable
the breakpoint in the Servlet since we won't need it any longer.
- Reload your input screen in your Web browser. Enter values and click Submit.
- You should get the correct JSP page this time, but with a null value
printed.
The next step is to Debug the JSP, and see if maybe we can
further fix the problem. Debugging the JSP
- In your Web perspective or any other perspective, navigate to the
AdderResults.jsp
file and open it.
- Click on the source pane to look at the source code for this JSP.
- Notice the first line that has a Java call is at line 48. It looks like
this:
String st1 = new java.lang.String(request.getParameter("str21"));
- Right-click next to this line and select Add Breakpoint.
- Reload
AdderInputForm.html in your Web browser.
- Enter any two strings in the fields in the input form and click Submit.
- Go back to the debug perspective (as explained in the previous section).
- Step Over the first two statements and verify that the variables
str1
and str2 hold the values you entered in the HTML form.
- Then on line 50, click the Step-into (
) button. This will take you to the code inside the AdderView
bean.
- Once you are inside the
AdderView source,
you'll realize that we are calling the wrong method. We should have been calling
the AdderView.strCat() method instead of AdderView.badStrCat().
- So now you'll need to go back to your JSP file, edit line 50, and change
it to:
String method0 = AdderBean.StrCat(st1 , st2 );
- Save your JSP. Do not remove the breakpoint (we will need it to demonstrate
the client debug and EJB).
- Reload your input form. Enter two different values in the fields. For example
-- "Hello" & "World", and click submit.
- You'll now notice that the null has disappeared, but we are getting
a concatenation of the first string to itself.
To fix this bug we'll need to debug the JSP call to the EJB
again.
Debugging of EJBs We used an EJB access bean to access the session bean that
does the string concatenation. Trying to step into the call to an EJB would
get us into a maze of stubs and server generated code. It is common practice
in cases like these to set a breakpoint on the EJB inside the problematic call.
In our case this is the AdderSessionBean.StrCat().
- Open the
poc.debug.ejbs.AdderSessionBean.java from the AdderEJB
project in either a Java or a J2EE perspective.
- Add a breakpoint at the first execution line of the
StrCat
method.
- Reload your input form. Enter two different values in the fields (that is,
"Hello" and "World"), and click Submit.
- You will first hit the breakpoint inside the JSP. Step over the first two
lines and then step into line number 50.
- In the
AdderView.StrCat method, step over the line that looks
like this: ret = bean.StrCat(str1, str2);
Note that in this case the AdderView
bean that runs within the App Server space is actually the client for our
EJB, but they share the same JVM in this specific case. So if you look inside
the stack of execution in the Process view, you'll realize that they are running
on the same process. Another client which is in the EJBclient.zip
can be used as a stand-alone Java application to test your EJB. When you add
this client to any Java project, make sure that you add the following to your
project build path.
- j2ee.jar *
- ijvejb35.jar *
-
AdderEJB project
(*) This files can be located in the <WASROOT>\plugins\com.ibm.etools.websphere.runtime\lib
directory.
When you debug this Application you will notice two important
facts:
- There are two separate processes. One for your application and one for
the EJB server.
- WebSphere Studio Application Developer debugger has the great ability
to step back and forth from one JVM to the other as your code executes.
- Click the Step-over (
) button and you'll notice that the debugger will stop on the breakpoint inside
your EJBs StrCat method.
- Stepping through the EJB, you'll realize the bug. We are simply appending
str1 twice, and not using str2 at all.
- Fix this problem and save your code.
- You will need to restart the server to refresh the EJB code. Don't forget
to start it in Debug mode. Unlike the case of Servlets and JSPs, WebSphere
4.0 will require a reload of the server when you change the code inside your
EJBs.
- Reload your input form, input your data, and trace your code into the EJB
statement.
- Verify that
sf variable does carry the correct
value. Note that if you click the Return ( 
) button from the EJB, you'll run back into the server-generated EJB classes.
To avoid that, just select the JSP call in the stack, as shown in Figure 7
below. Then you can use the Step-over (
) button and continue your execution in the JSP file.
Figure 7. Debug process view with JSP selected
- Verify that the return string carries the correct values (the concatenation
of your input strings).
You are now successfully competed debugging the problematic
Servlet, JSP, and EJB code.
Conclusion What we have done in this hands-on so far is to show you how
to use the WebSphere Studio Application Developer development environment to
debug your Java applications, Servlets, JSPs, and EJBs in different situations.
In the next article, we will show you how to use the WebSphere Studio Application
Developer debugger to debug applications running inside a remote instance of
WebSphere AE.
Download | Name | Size | Download method |
|---|
| DebugInWSADpt1.zip | 60 KB | FTP|HTTP |
About the author | 
| |
Ahmed Khalifa works for the VisualAge® and WebSphere Worldwide Enablement
team at the IBM Toronto software lab. His career started back in 1986, in the
hot summer of Upper Egypt, when he wrote his first spreadsheet using Basic on
a Commodore 64. In 1990, Ahmed received an engineering degree in architecture
with a diploma in computer science, and then worked on CAD applications using
C++. He joined Apple in 1991 and IBM Egypt in 1993, where he worked on the development
of Arabic APIs for OS/2. He joined the Toronto Lab team in 1997. Ahmed can be
reached at akhalifa@ca.ibm.com. |
Rate this page
| |
