|
|
EJB applications are complex in nature and the user typically writes the business logic and would want to debug only the business logic. Traditional debuggers cannot handle this but Studio debugger can.
Studio offers a smart debugger designed to help the developer find and fix bugs across all tiers of an enterprise application. Use the debugger to:
The Debugger and its features have been explained using a series of examples. To know how to use the debugger, read the entire chapter. The examples used are:
iBank to understand the Debugger in general and
Game of Eight to understand Conditional Debugging.
JSP Debugging assumes that the application has been deployed on the in-built Pramati Server.
Follow the given steps to know how to start the debugger:
This brings up the Debugger Settings dialog with two tabbed panes: Debug and Source.
The first pane is where the Debug options are to be set. The three options provided are - Applications for J2EE, Remote Application and Other.
Application for J2EE This option is selected when the application being debugged is a J2EE application. This option is selected when deployed application is to be debugged on any one of the configured servers from inside Studio.
Remote Application This option is selected when the application is to be debugged remotely. Enter the IP Address and Port number before debugging the application remotely. For more details the section - Remote Debugging.
Other This option is selected for any other application. Enter the main class name in the Main Class field.
JVM Options To debug the application using some special JVM options, use this field. This field is optional.
This panel lists the sources to be debugged. The following are the paths that can be edited:
Source Path Decide all the sources to be debugged. If you remove a specified source path using the button with the subtract icon, the Debugger does not debug the particular file. You can also add Java sources using the Add button.
Class Path This helps add any additional classes required for debugging the application and the same can then be removed.
This starts the Server in the debug mode. The next step for the user is to explicitly deploy the application or modules whichever is required.
While starting the Debugger, if the error message "no `classic' JVM at <jdk_install_dir>/jre/lib/sparc/classic/libjvm.so'. Server Stopped" is displayed, then follow the given steps and restart the Studio:
-Dcom.pramati.useClassicVM=false after the command java
The following section describes how to deploy applications that are to be debugged in Studio.
This deploys the Desk using Express Development. If there are references to be added or any mappings to be completed, the Deploy tool comes up.
The next step to perform is to set breakpoints in the application. To know all about breakpoints, read the following sections.
While large enterprise applications are typically multi-threaded in nature, even simple Java programs do have many threads executing.
Once the execution of a thread in a program being run in debug mode reaches a breakpoint in the code, it stops. At this point, the thread is suspended and the stack for this thread can be inspected. Other threads execute asynchronously but are not shown in the combo box.
Breakpoints should be inserted on an executable line of code either before or after the Debugger has been started.
Breakpoints can be set on any executable line of code in Java or JSP file. The execution is stopped when the control flow reaches the line on which the breakpoint has been applied. The JSP file can be debugged only when the application has been deployed on the in-built Pramati Server.
A breakpoint on a comment line or a blank line is ignored, as the control flow in a program does not pass through such lines.
Debug > Insert Breakpoint
The above-mentioned method inserts the breakpoint at the specified line. Alternatively, right click the line on which the breakpoint is to be set and choose on Insert Breakpoint. This can be performed using the keyboard shortcut, F9.
Debug > Remove Breakpoint
The above-mentioned method removes the breakpoint from the specified line. Alternatively, right click on the line on which the breakpoint set is to be removed, and choose on Remove Breakpoint.
This section describes how to launch the JSP.
This will directly launch the JSP in a browser set by you. The specified browser comes up with the following URL: http://127.0.0.1:8181/bankWeb/bank.jsp where bankWeb is the context root for the application.
After accessing the application, go back to Studio again. Studio now looks
like this:
The Debugger is composed of the following parts:
The editor contains the pop-up menus for toggling breakpoints set in Java or JSP code. The editor highlights the line where the control is paused.
The Output tab comprises a TextField and a TextArea. The TextField is used for entering command line inputs. The status and error messages from the debugger and the program output are displayed in the TextArea. In case of remote debugging or J2EE debugging, the Output Tab is not displayed.
This tab contains two combo boxes, two buttons, and the list displaying the ControlFlow:
It displays the different VMs in which the applications are being debugged.
It lists the user threads that are suspended, and also shows the thread hierarchy.
This button allows debugging of the application. It is enabled by default. When the button is disabled, it disregards all breakpoints and continues execution.
This button continues execution until it reaches the next breakpoint.
This button displays the flow of control. It is not the complete stack trace, but is filtered to show only those entries for which the source files are available.
The list shows the stack trace at the point where the execution of the program has been paused at some line due to a debug event. Like when a breakpoint is reached or after executing a step. It displays how the control has reached this point. Clicking on one item will open the file in the editor, with the particular line number highlighted.
A debug event is when program execution pauses at a breakpoint or watchpoint. The debugger displays the stack only for those threads that are suspended. So, if two threads reach a breakpoint, separately, their stacks would be shown separately. All suspended threads are shown in the Thread Combo. When a suspended thread from this combo is selected, the trace for this thread is shown.
It shows the stack at the point of execution. Variables are classified as Class Level (applicable throughout the class) and Local Level (applicable in a local scope). The name and value of each of the type of variable is displayed in the Variable Viewer in two separate panes. If the variable is an Object or an array, the contents are displayed in the tree format.
The values of variables in the Variable Viewer tab can be changed while the application is being debugged. These variables have to be primitive variables or Strings. To change the value of the variable, click on the variable value in the Variable Viewer tab and enter a valid value for that data type.
The Variable Viewer shows the stack at the point of execution. Variables are classified as Class Level (applicable throughout the class) and Local Level (applicable in a local scope). The name and value of each of the type of variable is displayed in the Variable Viewer in two separate panes.
If a variable is an array (or an object), its name is shown in red (or blue). By double clicking on it, the internal structure of the object can be seen.
VM maintains the local variables on the stack separately for each namespace. This is called the Stack Frame. When the control flows from one namespace to another, variables in the new namespace are maintained separately on a different Stack Frame.
VM maintains stack frames in an order called the Stack Trace. The frames are arranged with the latest one on top (control flow is bottom up). So by studying the stack, one can see how the control reached a point.
The stack trace shows only those frames for which the code is present. Therefore, while debugging Enterprise JavaBeans, those frames maintained for the containers, for instance, are not shown. This makes the stack trace easy to infer.
By single clicking on a stack frame, you can bring up the file into the editor, with the line number highlighted. In the output panel, the Variable Viewer shows class and local variables at that location.
Thread scheduling is fully dependent on the Operating System. Potential dead lock situations cannot be predicted. Thread scheduling is different when the application is run in the debug mode. So it is possible that the application executes as expected when you trace it step by step in debug mode but not when run in non-debug mode.
Once you have set the breakpoint and started the debugger, the following functions can be performed after the first breakpoint is reached:
Debug > Step In/ Step Over/ Step Out
The debugger will pause at the breakpoint. You can then step into the method, step out of method, step over a method, and resume the thread that has been suspended.
Case #1: Next line of code is not a method call.
In such a case, the debugger simply executes the code and stops immediately after.
Case #2: Next line of code is a method call.
The debugger, in this case will stop in the first line of code of the method that has been called, provided you have the source code for it.
If you do not have the source code for the method called, then the debugger just executes that method and stops
Stepping into Java core classes and Pramati classes is not allowed. This way you step into classes for which the source code has been written.
Object obj = ic.lookup("java:comp/env/ejb/MyChecking");in the bean file TransferBean.java. This is called transparent debugging, where the control smoothly flows from JSP files to EJB files and back. Note that this happens only when the application has been deployed on the in-built Pramati Server.Irrespective of the next line of code being a method call or not, the debugger executes the line of code, and the control stops at any breakpoint it encounters, or immediately after. This is conditional on the availability of the source for the next line of code to be executed. The debugger does not stop if the next line of code to be executed is in another class for which you do not have the source.
The debugger executes the current method and the control
This is conditional on you having the source code. When execution of a logical block of code ends, if you step in or step over, then the execution stops at the beginning of the logical block and highlights that point.
If you step in or step over a line of code that is not a "break" or a "return" statement, then
|
Step In/Step Over at
|
Highlight Position
|
|---|---|
|
Last line in a try block
|
The beginning of the try block
|
|
Last line of method
|
Declaration of method
|
|
Last line of condition
|
The condition
|
The above is true of any JPDA compliant debugger. If a line of code has multiple statements (implicit or explicit), and you step in, the debugger still highlights the same line. This happens because the debugger is trying to step into the method calls it encounters and bounces back because you do not have the source for it.
Example
Consider this line of code: System.err.println("The value of object x is "+x); Here the '+' overloaded operator actually is a method call to the append() method of class StringBuffer and the call to the toString() method of object x is not so obvious.
A breakpoint cannot be set on a line that contains a non-executable line of code. While debugging, this location will display a message saying no executable line of code there.
Click on the button GO in the ControlFlow tab to resume a thread. When this command is used, the debugger executes the code till it reaches the next breakpoint.
Use the combo box in the ControlFlow tab, which displays a list of all threads that exist in the application. Using this list, select the thread.
To understand when to use conditional breakpoints, open the samples jspDesk from the following location <install_dir>/samples/ejb11/jspDesk/jspDesk.dsk. This brings up the Desk, jspDesk in Studio.
Conditional breakpoints are set when the breakpoint should stop the control flow at the executable line of code, only when the condition is true. The following properties have to be set here:
The conditional statement supports conditions only when the variable is of the number type. At runtime, if the Debugger is unable to understand the condition, then the breakpoint is treated like any other breakpoint.
This stops the execution of the debugger when the value of i is greater than 3.
This starts the debugger and the control stops at the line of code, where the conditional breakpoint has been set.
The process of running code on one computer from another computer is called Remote Debugging. Remote debugging should be used in cases, where an application encounters a problem on one networked computer that cannot be duplicated on other computers.
The computer where the application is debugged from is known as the Client Computer. The computer where the application to be debugged is running is known as the Remote Computer.
To debug applications remotely using Studio the application the following steps need to be followed:
Use the Debug > Disconnect from the main menu to disconnect the debuggee. This functions differently for different types of debugging.
Applications deployed on Oracle and WebLogic Servers can also be debugged from inside Studio. Refer subsequent chapters for details on working with WebLogic Server 6.1 and Oracle 9iAS.
JavaServer Pages are converted into Servlets and Servlets are compiled to get the .class file. The Debugger maintains a one-to-one map of lines in the Servlet to lines in the JSP that is created at compilation time. Thus when a breakpoint is set in a JSP, The Debugger reads the map and sets the breakpoint in the corresponding line in the Servlet. Subsequently, breakpoint or step-in events return the appropriate lines in the JSP. This makes JSP debugging smooth.
JSP Debugging requires that the application has been deployed on the in-built Pramati Server.
Enterprise JavaBeans allow developers to write complex business components in a single-threaded fashion. Though, inside the application Server, the EJB runs in a multi-threaded environment.
A bean call actually invokes a function on a stub. Studio Debugger auto-discovers calls made to bean methods and sets implicit breakpoints in the bean code.
Subsequently, a thread re-directed from a breakpoint in the JSP to the bean code hits the implicit breakpoint and pauses. This control flow to the method seems like any other Java step-into process.
| Pramati Technologies © Copyright |
   
|