Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

IBM WebSphere Developer Technical Journal: An Introduction to Debugging Using IBM WebSphere Studio Site Developer and Application Developer

Pete Nicholls (mailto:nicholls@ca.ibm.com), Manager, IBM Toronto Lab
Pete Nicholls is a manager at the IBM Toronto Lab. He is responsible for IBM Debugger and VisualAge ® TPF. He has been a debug user since he wrote his first line of code. You can reach Pete at nicholls@ca.ibm.com .

Summary:  This article introduces you to some of the features of IBM WebSphere Studio Site Developer that can help you when debugging your Web applications. The debugging functionality described in this article is also available in IBM WebSphere Studio Application Developer.

Date:  04 Jan 2002
Level:  Introductory

Activity:  2231 views
Comments:  

Introduction

This article introduces you to some of the features of IBM WebSphereTM Studio Site Developer that can help you when debugging your Web applications. The debugging functionality described in this article is also available in IBM WebSphere Studio Application Developer. The debug component is the same for both products, as are all of the features we will be using. This means that if you are using WebSphere Studio Application Developer, you can make use of this information. For more information, see the WebSphere Studio Application Developer Web site. For simplicity, I will only be referring to the Site Developer product in this article.

You can download WebSphere Studio Site Developer Beta 2 version or download Application Developer Preview version.

To get a feel for the debugging functionality of Site Developer, we will debug a simple problem using Site Developer's YourCompanyExample project. You can try these features yourself by setting up the YourCompanyExample project.

To load the YourCompanyExample project:

  1. From the workbench menu bar, select File => New => Project. If you do not see this, select Other and then select Project.
  2. Expand the Examples node and select Web.
  3. From the list on the right, select Your Company.
  4. Press Next.
  5. Press Finish to accept the defaults.
  6. The README.htm file should now be displayed in a browser. This provides a good overview of the project structure. If you want to follow along as you read, follow the link in the Configuring YourCompanyExample section for instructions on configuring the database required to run the samples.

Site Developer basics

Site Developer concepts that you should familiarize yourself with include perspectives and views. A perspective is a set of views in a layout in the workbench window. A view captures a set of information and presents it in a single unit. There are several perspectives available in Site Developer, including a debug perspective. By switching perspectives as you do your work, you are able to make more efficient use of the Site Developer workbench by seeing only those views that are relevant to your work at hand. The Debug perspective is shown in Figure 1 below.


Figure 1. Debug perspective
Screen capture of the Debug Perspective in Site Developer

Switching perspectives is as simple as selecting the perspective from the shortcut bar on the left side of the workbench or selecting the Perspective main menu item and choosing the perspective you wish to open.

You can also customize perspectives by adding, moving and removing views from a perspective so that you can see only the information you need. If you manipulate a provided perspective, it will remain that way until you reset it. You can create your own perspectives as well. For information about these and other Site Developer basics, refer to the Workbench Basics in the Concepts section of the workbench documentation, which is available in the Help perspective.


Preparing to debug

We will now start the debugging process. First, right-click on the YourCompanyExample project in the Navigator view, and select Run on Server from the pop-up menu. If you can't see the Navigator view, switch to the Web perspective. Selecting Run on Server will start the example on the built-in WebSphere Application Server. The server will start in debug mode with the default page of the example loaded in the Web browser view. At this point, you are ready to start your debugging session.


Figure 2. Default Server debugging perspective
Screen capture of the Default Server Debugging Perspective in Site Developer

While you can debug in this perspective (see Figure 2 above), you may get tired of the amount of clicking and moving that you have to do to solve problems. Instead, you can save your energy (for graciously accepting accolades after fixing the problem) by trying this:

  1. Run the project on the server (described above).
  2. Start a browser outside of the workbench and have it point to the application's URL. You can copy the address from the browser view in Site Developer. In our example, it is http://localhost:8081/YourCompanyExample/.
  3. Switch to the Debug perspective in Site Developer. From the workbench menu bar, select Perspective => Other => Debug. This will open the Debug perspective. It will look empty at first, but if you select the debug tab at the bottom of the upper left view, you will see the Debug view. Expand the server launch node (Screen capture of the button used to expand the server launch node) and you will see the WebSphere Application Server process. Expanding this node shows you all running threads. Do not panic. Not all of these threads belong to your program. The Debug perspective displays all Application Server threads.
  4. Position your windows so that you can see both the browser and Site Developer.

Solving the problem

The next step is to determine how we are going to debug a problem. The two approaches that I use are: analytic and synthetic. Analytic debugging involves working backward from effect to cause. Synthetic debugging is working forward from functioning code to find the error. The analytic approach is the simplest and works well in solving simple bugs. The synthetic approach is more time consuming, but useful when solving more complex bugs that involve application flow.

I will demonstrate use of the analytic approach in solving a simple problem in YourCompanyExample. Let's say that we've received a problem report indicating that the stock change calculation is incorrect. We have already started the application and set up things up for debugging, so we will first reproduce the problem by navigating to the employee page that shows the stock quote. If you want to follow along, do the following:

  1. In the browser, select Run this Sample from the middle of the page.
  2. Log on to the database.
  3. Select Employee Center at the top of the page.
  4. Log on as one of the employees. It doesn't matter which one.
  5. Look at the stock quote on the page.

You should see something similar to Figure 3 below, but without the error.


Figure 3. Stock change problem
Screen capture of the Your Company example displayed in the browser

In our example, the stock change is incorrect (those of you following along will need to use some imagination). We now need to work backwards from here to determine the cause.

The first thing we should do is determine which part of the application provides stock change information. There is more than one way to do this. If you were working with a real application, the simplest way would be to refer to product design documentation. But, since design documentation is often outdated (or doesn't exist in the first place), we need to determine where the stock change gets calculated.

In the Navigator view, select the YourCompanyExample project and right-click. From the pop-up menu, select Go To => Resource. This is a very handy way to find things. You can now type stock in the input field and the workbench will show you all resources that start with the characters you have typed. From this list, you can guess that StockBean.java is the resource that you should look at.

Another way is to right-click the browser page and choose to view the source for the page. The title of the source will be CenterGeneric[1] or something similar. This tells you that you need to look at CenterGeneric.jsp. Use the method described earlier to find CenterGeneric and then double-click it to open CenterGeneric.jsp in the JSP Editor. Initially, the source will be displayed, but you can select the Design tab at the bottom to see the page laid out with its design items. Select the stock change item. You can do this by looking at the page in the browser and then selecting the corresponding position on the Design view. This will enable a JSP expression pull-down menu at the top of the view. In the pull-down menu, choose Attributes of JSP Expression. You will see that you need to look at stockBean.getStockChange(). See Figure 4 below.


Figure 4. Attributes of JSP Expression
Screen capture displaying the attributes of the JSP expression

Now go to StockBean.java and set a breakpoint in getStockChange(). To do this, open StockBean.java and go to the getStockChange() method. Double-click in the ruler on the line in which you want to set a breakpoint. You will see the little green circle appear, indicating that a breakpoint has been set. Optionally, you can also position the cursor on the line, right-click and choose Add Breakpoint. Another nice feature of Site Developer is that you do not need to be debugging to set breakpoints. You can set them at anytime and they will be installed when the debugger starts.

Now, reload the page in the browser and the Debug perspective will stop on the breakpoint.

At this point, you should get a feel for the various views that we will use to solve this simple problem. When you are debugging more complex applications, you can use the same methods.

The first view that we will examine is the source editor. This is the source that I am trying to fix. I have stopped at the first line in the method:

 
 
public int getStockChange() { 
 
   this.stockChange = stockQuote + stockBase; 
 
   return this.stockChange; 
 
}


The Debug views

Debug view


Figure 5. Debug view
Screen capture of the Debug view

The Debug view is used to control the execution of the debugger. For each debug launch, the view shows the threads and stack frames. To navigate in this view, select the suspended thread and expand it as shown in Figure 5 above. The stackframes will be displayed. Select the top one and the source view will show the current line in that method. The buttons on the toolbar at the top of the view allow you to control execution, as follows:

  • Screen capture of the resume button resume This will resume execution.
  • Screen capture of the step into button step into This will step into the line and execution will stop on the next line.
  • screen capture of the step over button step over This will step over the current line and stop on the next line in this stack frame.
  • Screen capture of the step return button step return This will return from the current stack frame.
  • Screen capture of the suspend button suspend This will suspend execution allowing you to set breakpoints, change variables, and so on.

Execution has stopped where we want it to so we do not need to do anything further with this view. In a more complicated scenario, you would use this view to control the application by stepping, resuming or suspending execution.

Now, let's look at the variables to help us figure out what went wrong.

Variables view


Figure 6. Variables view
Screen capture of the Variables view

The Variables view (Figure 6 above) shows the variables for the current stack frame. To display type info, click the following button: Screen capture of the button used to display type info. To show static and final variables, you need to press the corresponding buttons: Screen capture of the button used to show static variables , Screen capture of the button used to display final variables. From this view you can change the value of a variable by right-clicking on the variable, and choosing Change Variable Value. For our current problem, we do not need to change any of the values.

Since the values look correct, let's take another look at the code. The plus sign is a little suspect and may not be correct operation. Let's try a couple of things out in the Inspector View.

The Inspector view lets you inspect expressions. To do this, highlight the line in the source that you want to inspect, right-click and choose Inspect. This evaluates the expression and shows the result. After thinking for a minute, you might decide to subtract instead of add. You can now change the plus sign to a minus sign in the source editor, highlight the line again, right-click and choose Inspect. This will then show you a much better result, as can be seen in Figure 7 below.

Inspector view


Figure 7. Inspector view
Screen capture of the Inspector view

This now looks like the correct thing to do. You will need to save the change to StockBean.java, which is as simple as pressing CTRL-S.

Because StockBean.java has been changed, you will need to resume debugging by pressing the resume button on the debug view. You will still see an incorrect result in the stock change field because, although we have fixed the code, we need to reload the application to pick up the fix. To see the correct results, go back to the browser and reload the main page again. You can then navigate through to the failing spot and see the correct stock change value.

There are cases where you do not have to start over by reloading the main page but, for simplicity, I recommend that you start over until you gain more experience debugging with Site Developer. If you do not start over and notice that your change is not picked up or that you suddenly start getting errors, just go back and reload the first page. If this does not work, then terminate the debug session and start another one.


Conclusion

I have shown how to solve a simple problem and, along the way, demonstrated some of the debugging features available to you in WebSphere Studio Site Developer and Application Developer. There are other features I did not talk about and you can learn more about these by working through the Site Developer samples, reading the help documentation, or just experimenting.


About the author

Pete Nicholls is a manager at the IBM Toronto Lab. He is responsible for IBM Debugger and VisualAge ® TPF. He has been a debug user since he wrote his first line of code. You can reach Pete at nicholls@ca.ibm.com .

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.


Report abuse help

Report abuse

Report abuse submission failed. Please try again later.


developerWorks: Sign in


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


Rate this article

Comments

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=14200
ArticleTitle=IBM WebSphere Developer Technical Journal: An Introduction to Debugging Using IBM WebSphere Studio Site Developer and Application Developer
publish-date=01042002
author1-email=mailto:nicholls@ca.ibm.com
author1-email-cc=