You are on page 1of 16

Using the Eclipse Platform to debug Java applications on

HP NonStop servers

Debugging a standalone Java application .............................................................................................. 2


Debugging servlets in NonStop Servlets for JavaServer Pages Version 3.0 Software .................................... 7
Debugging a BEA WebLogic Server application.................................................................................... 13
For more information.......................................................................................................................... 16
This paper offers an introduction on how to use the open-source Eclipse Platform to debug Java™
applications running on HP NonStop servers. It assumes a basic knowledge of Eclipse and describes
how to configure the server side to connect to the remote server. Three different examples are
presented that should help in debugging most Java applications:

• Debugging a standalone Java application


• Debugging servlets in NonStop Servlets for JavaServer Pages Version 3.0 software
• Debugging a BEA WebLogic Server application

Debugging a standalone Java application


This example assumes a familiarity with Eclipse sufficient to create a standalone Java application. It
contains a class called DebugMe that accepts a parameter and prints out a line xx times. The source
code in the Eclipse integrated development environment (IDE) looks like the following.

As you can see, a breakpoint is enabled at line 39. To enable a breakpoint, double-click the vertical
bar at the left of the source. The blue dot in the vertical bar indicates the location of the breakpoints.
Float the pointer over the dot to display a tool tip with some extra information.
After transferring the JAR file with the class to the NonStop system, run the program as follows:

java –classpath ./debug_standalone.jar nscc.cg.debug.sa.DebugMe –count=5

2
Here is the output of the program:

received this value for x: 0


received this value for x: 1
received this value for x: 2
received this value for x: 3
received this value for x: 4

To run the program in debugging mode, you need to give it the correct parameters. Instead of putting
them on the command line, use the _JAVA_OPTIONS environment variable, which allows you to
change options for Java without giving them as Java Virtual Machine (JVM) arguments. Although not
important in this example, this is handy when you use shell scripts to start the Java program. Instead
of having to edit the shell script, you can now just change the value of the environment variable as
follows (should not be on one line):

export _JAVA_OPTIONS=”-Xdebug -Xnoagent -Djava.compiler=none


-Xrunjdwp:server=y,transport=dt_socket,address=16123,suspend=y”

Following is an explanation of the parameters:

-Xdebug Enable debugging mode.

-Xnoagent Disable the “traditional” debugging mode; use the Java Platform Debugger
Architecture (JPDA) agent.

-Djava.compiler=none Disable bytecode compilation.

-Xrunjdwp: JPDA-specific connection information and settings.

server=y Instruct the JVM to listen for the external debugger (Eclipse) to attach at the
specified address.

transport=dt_socket Tell the debugger to use the network connection (TCP/IP).

address=16123 If dt_socket is used, this is the TCP/IP listen port.

suspend=y Suspend the program at startup; this means that the program should wait for
the remote debugger to connect to it before continuing.

Run the program as previously described. Alternatively, if you had an executable JAR file, that is, a
file in which there is a manifest that tells you which class to call automatically, you could use this text:

java -jar debug_standalone.jar -count=10

However, continuing with this example, call the same command again:
java –classpath ./debug_standalone.jar nscc.cg.debug.sa.DebugMe –count=5

Following is the output:


Picked up _JAVA_OPTIONS: -Xdebug -Xnoagent -Djava.compiler=none -
Xrunjdwp:server=y,transport=dt_socket,suspend=y,address=16123

The line that starts with “Picked up” shows which flags the JVM has accepted. Notice that now there is
no output from the program. It is waiting for the debugger to connect to it. So next, you have to
configure the debugger in the Eclipse IDE as follows:

1. On the menu, choose Run > Debug …. The following screen appears.

3
2. Select Remote Java Application and either right-click this item and select New, or click the New
button. The following screen appears.

4
3. As Name, use the proposed one (DebugMe), or specify any name you like. The connection type
defaults to Standard, which corresponds to the specified dt_socket. The Host is the name or IP
address of the NonStop server. Make sure that you use the one that corresponds to the TCP/IP
process you use when you run the Java program. The Port is the port specified in the address field
in the runjwdp options. Since we used 16123 there, that value is copied here.

4. Start debugging by clicking the Debug button on the bottom of the dialog box. Eclipse asks if you
want to use the Debug perspective. Click Yes to get a better overview of all the windows.

The following screen appears.

5
As you can see, the debugger started the program and halted at the first breakpoint encountered,
which is at the start of the program. This situation might be completely different in your environment.
The window at the bottom left contains the source of the debugging program. Remember, blue dots
are breakpoints, where the debugger will halt the code. The window above it (called Debug) contains
an overview of all the running threads in the Java program. The window at the top right (Variables)
contains a tab for the breakpoints and one for the variables from the current scope. You will see this
change, for example, whenever a new method is called. Currently it points to the variables known in
the main method: an integer count and a String[] args.
The Variables window allows you to look at the contents of these variables. When you continue with
the program using the Step commands, this window emphasizes all changes by coloring them red.

6
You can perform stepping by either clicking the buttons in the Debug toolbar or by using function keys
F5 (step in) and F6 (step over).

Click Resume to continue with the program and to encounter the next breakpoint. From here, you can
take control to display and inspect all variables. Float the pointer over a variable in the source code
to see its value pop up as a tool tip.

The same technique applied in this example can be used to debug servlets and Enterprise JavaBeans,
as shown in the following examples.

Debugging servlets in NonStop Servlets for JavaServer


Pages Version 3.0 Software
Using the same technology as in the previous example, you can instrument the NonStop Servlets for
JavaServer Pages (JSP) container to debug it with Eclipse. Instead of using the parameters for
debugging on the command line or in the _JAVA_OPTIONS environment variable, include them in the
servlet.config file, which is used at the startup of HP iTP WebServer Software.
Here is the text used in this example:

7
#
Server $server_objectcode {
CWD $env(NSJSP_HOME)
Env CLASSPATH=$JVCP:$USRCP
Env JAVA_HOME=$env(JAVA_HOME)
Env JREHOME=$env(JAVA_HOME)/jre
Env TCPIP_RESOLVER_ORDER=HOSTFILE-DNS
MapDefine =TCPIP^PROCESS^NAME /G/ZSAM1
Maxservers 1
Maxlinks 250
Numstatic 1

#
Linkdepth 25
Env TANDEM_RECEIVE_DEPTH=25

#
# File locations to direct standard input, output and error.
#
Stdin /dev/null
Stdout $root/logs/servlet.log
Stderr $root/logs/servlet_error.log
#
# This is the actual Arglist used to start up the NSJSP Container.
#
# Note: All of this should be on one line.
#
Arglist -Xdebug -Xnoagent -Djava.compiler=none
-Xrunjdwp:server=y,transport=dt_socket,suspend=n,address=16124
-Xnoclassgc –Xmx64m -Xss128k -Dbrowserdebug=false
-Djdbc.drivers=com.tandem.sqlmp.SQLMPDriver $NSJSP_SECMGR
$NSJSP_SECMGR_POLICY -Djava.endorsed.dirs=$env(NSJSP_ENDORSED_DIRS)
-Dcatalina.home=$env(NSJSP_HOME)
-Djava.io.tmpdir=$env(NSJSP_HOME)/temp com.tandem.servlet.NSJSPBootstrap
-config $env(NSJSP_HOME)/conf/iTP_server.xml start

Filemap /debug $server_objectcode

Lines in bold were changed from the default for the following reasons.
• Maxservers 1 and Numstatic 1: To debug this environment, you need to be sure that the Eclipse IDE
connects to the correct process. Remember that you are now listening to a TCP/IP socket. Although
PTCP/IP and NonStop TCP/IPv6 Software allow you to have multiple listeners on the same port,
you cannot not be sure if the IDE connects to the same instance where the client or browser calls the
servlet. By setting these values to 1, you have no doubt.
• -Xdebug -Xnoagent -Djava.compiler=none
-Xrunjdwp:server=y,transport=dt_socket,suspend=n,address=16124: This looks exactly the same as
in the standalone example, except for one small change: suspend=n. This tells the JVM not to wait
until the debugger connects, but to continue working and to listen to the port (16124). This is
necessary because the servlet engine is a Java program that needs to initialize itself before it can
accept requests from clients. If you have a servlet engine that hangs during startup when
debugging, check this parameter.

8
• Filemap /debug $server_objectcode: This line is not really needed for debugging, but it needs to
be there so the HTTPD knows that it should forward requests for the /debug context to the servlet
engine and not process them.

As an extra, here is the context used in this application from the file iTP_server.xml:

<Context path="/debug" docBase="/home/cor/mywork/debug/servlet"


reloadable="true" debug="0"/>

This context tells the servlet engine where it should look for the files belonging to the Web application.
Restart the Web server to accept the new parameters and switch to the Eclipse IDE. This example uses
a breakpoint in the code at the first output statement, but you can use whatever you like.

On the menu, choose Run > Debug … and fill in the correct parameters as follows.

9
The only difference between this example and the standalone one is that port 16124 instead of port
16123 is used for the servlet.
Switch to the debug perspective and note that the DebuggeeServlet appears in the Debug window.

10
As you can see, there are already many active threads, which were started by the servlet engine to
do different work. Next, use your browser
(http://yourhost:16080/debug/servlet/DebuggeeServlet?param1=tester&param2=333) to call the
servlet with a simple GET method. Once this page is called, the code activates the breakpoint that
you set in the source, and you need to switch to the Eclipse IDE. The following screen appears.

11
The parameters param1 and param2 are now in the String variables, as you can see in the Variables
window at the top right. The Debug window shows which thread is active (doGet()), and the arrow on
the left of the source code shows where you are in the code.
Next use the Step commands, as before, to inspect the code. At the end of the doGet method, control
will be given back to the servlet engine, so don’t forget to Resume (F8); otherwise, you will start
debugging the Tomcat code, which is something you usually do not want to do.
Finally, your browser displays the following:

12
Debugging a BEA WebLogic Server application
This example shows how to debug a servlet and Enterprise JavaBeans (EJB) running inside a BEA
WebLogic Server Version 8.1 SP2 environment. It is similar to the previous examples.
Since WebLogic Server is usually started with a shell script, this example uses the _JAVA_OPTIONS
variable again. To avoid that would mean changing the script in between different sessions. For this
example, a small servlet (called DebugMeServlet) and an even simpler EJB (called DebugMe) have
been created. The servlet accepts two parameters (as before) and forwards them to the “business”
method in the stateless EJB, which concatenates the strings after converting them to uppercase.
An EAR file created with both applications has been deployed in WebLogic Server and can access
them. To place WebLogic Server in debugging mode, use the _JAVA_OPTIONS variable (everything
should be on one line):

export _JAVA_OPTIONS=”$_JAVA_OPTIONS -Xdebug -Xnoagent


-Djava.compiler=none
-
Xrunjdwp:server=y,transport=dt_socket,suspend=n,address=16125”

The statement looks the same as in the NonStop Servlets for JavaServer Pages example (suspend=n)
because you want WebLogic Server to do all its initialization work before you continue. Use a startup
script to start the server and switch to the Eclipse IDE. This example includes a breakpoint set at a line
in the servlet.

Another breakpoint has been set at a line in the EJB.

13
Use Run > Debug … to create a connection for the remote machine.

This example uses a different port than previous examples, but otherwise, nothing is different. Click
the Debug button to connect the IDE with the remote server.

14
Use your browser
(http://yourhost:16801/Debug/servlet/DebugMeServlet?param1=aaa&param2=bbb) to connect to
the environment. As soon as you press Enter, the Eclipse IDE shows the breakpoint in the servlet.

15
Click Resume (or press F8) to display the next breakpoint (in the EJB).

Just as in previous examples, use the necessary step commands to examine your source and the
variables. And don’t forget to Resume at the end, because you don’t want to debug WebLogic
Server.

For more information


For more information on the Eclipse Platform, visit www.eclipse.org. Also, see the HP paper Enterprise
application development using Eclipse at
http://search.hp.com/redirect.html?type=REG&qt=nonstop+eclipse&url=http%3A//devresource.hp.c
om/drc/resources/eclipse_entappdev/index.jsp&pos=14.
For more information on NonStop servers, go to www.hp.com/go/nonstop.

© 2004 Hewlett-Packard Development Company, L.P. The information contained


herein is subject to change without notice. The only warranties for HP products and
services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or
omissions contained herein.
Java is a U.S. trademark of Sun Microsystems, Inc.
09/2004

16

You might also like