Debugging applications for JBoss AS in IntelliJ IDEA 9 or 10

From IntelliJ-Wiki

Jump to: navigation, search

This is the second tutorial in the series dealing with integration of IntelliJ IDEA with JBoss Application Server (JBoss AS). So it is assumed that you have already studied the previous tutorial “Developing applications for JBoss AS in IntelliJ IDEA” (the version for IntelliJ IDEA 9 or 10) and completed all the tasks contained therein. If not, please, do so first.

This tutorial discusses:

  • Preparatory steps. These are the actions needed to get to the state which you were at when completing the previous tutorial. If you have just finished “Developing applications for JBoss AS in IntelliJ IDEA” and haven’t yet quit IntelliJ IDEA, skip this section.
  • Spoiling the source code and observing the application behavior. This section shows how to “spoil” the source code developed before to make the sample application behave peculiarly.
  • Debugging the sample application. In this section you’ll find explanation and instructions for the most typical debugging tasks.


Preparatory steps

To get to the state you were at when completing the previous tutorial, do the following:

1. Start IntelliJ IDEA.

2. Open your sample project (presumably, C:\IdeaProjects\JBossSampleApp).

3. If the file process_name.jsp is not already open in the editor, open it.

Now you are ready to start modifying the code.

Opening the sample project

To open your sample project:

  • Select File | Reopen and click JBossSampleApp (or C:\IdeaProjects\JBossSampleApp).


If the sample project is not present in the list of recently used projects, try opening the project like this:

1. Select File | Open Project.

2. In the Select Path dialog, find the project JBossSampleApp in the file system, select it, and click OK.


Opening process_name.jsp

To open the file process_name.jsp in the editor:

  • In the Project tool window, double-click the file. (Alternatively, select the file and press F4.)


Spoiling the source code and observing the application behavior

To show how to debug JBoss AS-oriented applications in IntelliJ IDEA, we have slightly “spoiled” the source code of the sample application. We made one simple intentional mistake in process_name.jsp, the file that is responsible for the main part of the application logic. As a result, the application behavior has become somewhat peculiar.

Now we suggest that you do the same, namely:

1. Modify process_name.jsp

2. Study the application behavior

After that we will debug the application.

Modifying process_name.jsp

Replace the <body> element (<body>...</body>, inclusive) with the following:

            String headingText = "Oops!";
            String messageText = "You forgot to specify your name.";
            String linkText = "Back to logon page";
            String name = request.getParameter( "userName" );
            if (name != "") {
                session.setAttribute( "visitorName", name );
                headingText = "Hi, " + name + "!";
                messageText = "Thank you for visiting our home page.";
                linkText = "Log out";
        <h1><%= headingText %></h1>
        <p class="message_text"><%= messageText %></p>
        <p><a href="index.jsp"><%= linkText %></a></p>

Studying the application behavior

To run the sample application and study its behavior, do the following:

1. Make sure that the appropriate JBoss Run/Debug configuration is shown in the Run/Debug configuration selection box on the toolbar, and click Run File:icon_run.png. (Alternatively, press SHIFT+F10.)


After a little while, the default Web browser starts and goes to http://localhost:8080/JBossSampleApp_war_exploded/. As a result, the starting page of the sample application is displayed.


2. Type something in the User name field (for example, John) and click Log on.


The browser switches to process_name.jsp, and you see the following:


At this point, we would expect to see “Hi, John!” rather than “Hi, null!” The rest of the page, however, seems reasonable.

3. Click Log out to come back onto the starting page.

4. Now click Log on without specifying the name.

Note that you get the same result as before instead of an error screen.

(See how the sample application should work if you don’t remember.)

5. Close your Web browser (or the tab where you were working with the sample application).

6. Stop the server (File:00_icon_stop.png, CTRL+F2, or Run | Stop).

Now we are going to study our application in more detail by running it in the debugger.

Debugging the sample application

Debugging workflow in IntelliJ IDEA normally includes performing the following typical tasks:

1. Starting the application in the debug mode

2. Inserting one or more breakpoints in the source code

3. Executing the code line by line to get a detailed picture of what is going on inside the application

4. Making an assumption about what is wrong and checking this assumption. In IntelliJ IDEA, you can check such assumptions, for example, by evaluating expressions.

5. Resuming the application to get to the next of the breakpoints or see how the application behaves after the part you have scrutinized.

Usually, after performing these tasks, you can correct the source code and check if this has eliminated the problem.

The following sections provide the corresponding how-to examples.

Starting the application in the debug mode

To debug the sample application, we’ll use the same Run/Debug configuration as for running the application. No changes are required to the debug settings provided by IntelliJ IDEA by default.

To start debugging the sample application:

1. Click the Debug icon File:icon_debug.png on the toolbar. (Alternatively, press SHIFT+F9.)


The debugger starts. As you can see in the Output pane of the Debug tool window, JBoss AS is started and the application artifact is deployed to the server. Then, the starting page of the sample application is opened in the Web browser that is started automatically. (Everything happens as specified in the Run/Debug configuration being used.)

Inserting a breakpoint in the code

Now let’s insert a breakpoint into process_name.jsp.

Because the executable part of the page is very small, we can limit ourselves to only one breakpoint and insert it at the very start of this part.

To insert a breakpoint:

1. Switch to IntelliJ IDEA.

2. In the editor, click the gutter area next to the line String headingText = "Oops!";


As a result, a red spot appears indicating the breakpoint that you have set.


Executing the code line by line

Now let us execute the code line by line:

1. Make the sample application run. To do that, switch to the Web browser. On the starting page of the sample application, type something in the User name field (for example, John), and click Log on.

As a result, the input data is submitted to the server. The control of the application is passed to process_name.jsp. When the breakpoint is reached, the application is paused.

2. Switch back to IntelliJ IDEA. Note that now the line String headingText = “Oops!”; in process_name.jsp is highlighted blue. This means that the application is paused at the beginning of this line.


3. To execute the current line of code, click the Step Over icon File:icon_step_over.png on the toolbar of the Debug tool window. (Alternatively, press F8.)


Look at the result. Note that the blue highlight in process_name.jsp has moved from String headingText = "Oops!"; onto the next line String messageText = "You forgot to specify your name.";


At the same time, a new entry appeared in the Variables pane (headingText = {java.lang.String}”Oops!”).


All this means that one line of code has been executed, and, as a result, the variable headingText has been assigned “Oops!” as its value.

4. Keep clicking File:icon_step_over.png (or pressing F8). Observe the result after each click.

When you have stepped over the assignment of the variable name, notice that its value is null (that is, it has no value). Obviously, this is what the method request.getParameter() returned.


One of the possible reasons is that the method argument (“userName”) references a non-existing value. In other words, we may assume that the corresponding request object does not have a parameter with such a name. A bit later, we will check this assumption.

5. Now let’s continue executing the code to find out more about the debugger.

Note that as soon as a variable value changes, this is shown in blue in the Variables pane. Here is an example:


Continue until the line that contains %>.

By now we’ve got an idea of what is wrong with our application. So let’s check our assumption. We’ll do that by evaluating an appropriately constructed expression.

Evaluating an expression

To evaluate an expression:

1. On the toolbar of the Variables pane, click the Evaluate Expression File:icon_evaluate_expression.png icon. (Alternatively, press ALT+F8.)


The Code Fragment Evaluation (or Expression Evaluation) dialog is displayed.

2. If the Code Fragment Mode button is present in this dialog, click it to switch to the code fragment mode. Then, copy the following code fragment into the Statements to evaluate area:

String parameterNamesString = "";
java.util.Enumeration parameterNames = request.getParameterNames();
while (parameterNames.hasMoreElements()) {
    parameterNamesString = parameterNamesString + parameterNames.nextElement() + ",";
String result = parameterNamesString;


(This code fragment retrieves the names of request parameters one by one. The names are accumulated in parameterNamesString as a comma-separated list. The resulting list (as a string) is assigned to result.)

3. Click Evaluate. Then, scroll the Result area horizontally until you reach the end of the first line.


As you can see, the request that we are trying to process has only one parameter. The name of this parameter is username (rather than userName). So it seems that we have spotted the problem.

4. Click Close.

Let’s now resume the application and then make the necessary code correction.

Resuming the application

To resume the application:

  • In the Debug tool window, click the Resume Program icon File:icon_resume_program.png. (Alternatively, press F9.)


Correcting the code

In the line of code String name = request.getParameter( "userName" ); change userName to username.

Now let’s see if this change has eliminated the problem in the application behavior.

Studying the application behavior after the code correction

To check the application behavior:

1. Switch to the browser.

2. On the Hi, null! page that is currently shown, click Log out.

(Because the Update resources on frame deactivation option is active, and we’ve left IntelliJ IDEA, the sample application must have been updated by now.)

3. On the starting page, type John in the User name field and click Log on.

The application is again suspended at the beginning of the corresponding code line.

4. Switch into IntelliJ IDEA. Execute the code line by line as we did before.

After executing the line String name = request.getParameter( “username” ); note that now the variable name has a proper value (“John”).


5. Resume the application and switch to the browser to see the result.


6. Click Log out.

7. Now, as an exercise, repeat the debugging cycle without specifying the user name. You should finally get the error screen.


It looks like everything is fine. We’ve eliminated the problem and can now stop the server.

Stopping the server

To stop the server:

  • In the Debug tool window, click the Stop icon File:icon_stop.png. (Alternatively, press CTRL+F2.)


Personal tools