6.2 Sample scenario

 < Day Day Up > 

This section provides a sample scenario to illustrate how to debug portlets using the debug functions provided by WebSphere Studio Site Developer. You will use the portlet used in Chapter 5, "Action event handling" on page 181 as a base for this scenario. These activities will allow you to understand the techniques used to debug portlets.

6.2.1 Fixing compile errors

In this section, an example is provided to illustrate the use of the Java validator to validate Java code. An invalid character will be entered in the Java code to introduce an error and illustrate the correction process.

Note : WebSphere Studio provides different validators for different types of project resources, for example XML, HTML or Java files. In general, a validator is a process which validates a certain resource when you save it. After the validation process is finished, it displays the results of the validation in the Task view. To customize the validation settings, select Properties from the project context menu. In the Validation page, you can disable all or only certain validators.

To create a compile error, proceed as follows :

  1. In the J2EE Navigator, select ActionEvent-> Java Source-> actionevent-> ActionEventPortlet.java as shown in Figure 6-1 on page 215. Double-click the Java file; it will open in the editor in the upper right-hand portion of the screen. If the file is already opened, scroll to the top.

    Figure 6-1. Double-click ActionEventPortlet.java to open

    graphics/06fig01.jpg

  2. In the editor window, you should see a declarative statement:

     public class ActionEventPortlet extends PortletAdapter implements ActionListener 
  3. Place the letter x at the beginning of this statement to create an error. See Figure 6-2.

    Figure 6-2. Incorrect public class declaration

    graphics/06fig02.jpg

  4. Press Ctrl-S to save this file.

  5. The compilation process fails due to the error you introduced. In the Tasks view in the lower right-hand portion of the screen, an error message appears, as shown in Figure 6-3 on page 216.

    Figure 6-3. Result of saving an incorrect Java file

    graphics/06fig03.jpg

  6. Double-click the red error icon in the Tasks window. The problem area in the code will be highlighted.

    Tip : If you cannot see the whole error message in the Task view because of its length, move over the red error symbol to the left of the Java editor. A small help window appears with the whole error message.

  7. Remove the letter x before public to return the code to its original condition. Press Crtl-S . The code will be validated again, and the error message will disappear from the Task view.

  8. Close the editor by clicking the X on the ActionPortlet.java tab.

6.2.2 Debugging a portlet application

When developing portlets, you often have to detect programming errors. One of the exciting features in WebSphere Studio is the integrated debugger for detecting errors during runtime. In this sample scenario, you will set a breakpoint, start WebSphere Portal in Debug mode and modify the value of a variable.

  1. In the J2EE Navigator view, expand the ActionEvent project in the navigation panel.

    Figure 6-4. Select ActionEventPortlet.java to open it

    graphics/06fig04.jpg

  2. Browse to the /Java Source/actionevent/ folder and double-click ActionEventPortlet.java to edit it.

  3. The editor will open in the upper right-hand corner of the screen.

  4. In this portlet class, there are five methods :

    - init

    - doView

    - actionPerformed

    - doEdit

    - getJspExtension

  5. In the actionPerfomed method, you will set a breakpoint by placing the cursor on the setAttribute statement (this is the if clause that checks for ACTION_RED). Right-click the context bar to the left of the code, then select Add Breakpoint from the context menu as shown in Figure 6-5 on page 218.

    Figure 6-5. Adding a breakpoint

    graphics/06fig05.jpg

    Note : It is not necessary to highlight the entire line.

  6. After setting the breakpoint, you should see a dot of two possible colors in the context bar. If the breakpoint is blue, it is unverified, meaning that the containing class has not yet been loaded by the Java VM.

    If the breakpoint is green, it is verified , meaning that the containing class has been loaded by the Java VM, indicating that the breakpoint has been set.

    Note : This is the statement where the actionPerformed method has identified the action and set an attribute (setAttribute) in the request object; the attribute is to be rendered later in View mode.

  7. To test this portlet, the Test Environment must be running in Debug mode. Click Servers . If the Test Environment is started, right-click and select Stop and wait until you see the message indicating that WebSphere Portal has stopped .

  8. Once the Test Environment is stopped, right-click ActionEvent from the Navigator panel, then select Debug on server .

    Figure 6-6. Start the server in debug mode

    graphics/06fig06.jpg

  9. WebSphere Studio will change to the debug perspective. It will look as shown in Figure 6-7 on page 220.

    Figure 6-7. Debug perspective of Portal running the ActionEvent portlet

    graphics/06fig07.jpg

    Note : Starting WebSphere Portal in debug mode will take a few minutes.

  10. When the Step-by-Step Debug window appears, select Skip and Disable step-by-step mode , since you have already set a breakpoint, as shown in Figure 6-8 on page 221. Click OK and wait for execution of the portlet; the portlet will take extra time to execute in Debug mode.

    Figure 6-8. Disable the step-by-step mode

    graphics/06fig08.jpg

  11. The portlet will run in the built-in browser shown in the middle left panel (in the Debug perspective) or the upper right panel (in the Portal perspective).

  12. Now click Edit mode to select an action.

  13. Select the Red Action button; remember that the breakpoint has been set in this action path (actionPerformed method).

  14. The action (Red Action) will now execute up to the breakpoint you have previously set. When the breakpoint is reached, the Java editor displays the code and the statement with the breakpoint is highlighted.

    Figure 6-9. Debugger stops execution at the breakpoint

    graphics/06fig09.gif

  15. Place the cursor in the context bar where the breakpoint is located and right-click to select Remove Breakpoint from the context menu. Take a moment to examine the code before proceeding.

  16. From the Debug perspective, select the Variables view.

  17. Locate the variable value with a value of Action <FONT color =\"#ff0000\">RED</FONT> .

  18. Select the value variable, then right-click it and select Change Variable Value from the context menu.

    Figure 6-10. Changing the variable value in the Variables view

    graphics/06fig10.jpg

  19. Enter Action <FONT color=\"#00ff00\">GREEN</FONT> as the new value. Press Enter .

  20. Select the Debug view in the upper left. Click the Resume icon (green triangle on the left side of the toolbar icons).

    Figure 6-11. Click the Resume icon to resume the execution of the portlet

    graphics/06fig11.jpg

  21. The portlet application will continue its execution. Select the Web Browser tab from the display toolbar in the middle left panel of the screen. The result of the action will be displayed. Note that the action displayed in View mode is now Action GREEN ...was selected ! (and not Action RED ...was selected ! as originally shown).

    Figure 6-12. The ActionEvent portlet after changing a variable during debugging

    graphics/06fig12.jpg

    Note : If you start another action in Edit mode, there will be no changes since the breakpoint was cleared and no other changes have been made at this time.

 < Day Day Up > 


IBM WebSphere Portal V5 A Guide for Portlet Application Development
IBM Websphere Portal V5: A Guide for Portlet Application Development
ISBN: 0738498513
EAN: 2147483647
Year: 2004
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net