You can use the WebLogic Workshop integrated debugger to debug your
application. The debugger allows you to set breakpoints, step through your
code line-by-line, view local variables, set watches on variables, and view
the call stack and exception information.
A D V E R T I S E M E N T
There are a variety of
properties that can be set for the debugger. Some are set on a project
basis, while others apply only to Java and Control Projects.
You can use the debugger on runnable files, non-runnable files,
non-Workshop enabled servers, and projects developed against a remote
server. You can also attach to JUnit and use the JUnit functionality in
conjunction with the Weblogic WorkShop Debugger.
Using the Debugger
In order to debug an application, you must have a way to exercise the
application as a real client would. WebLogic Workshop includes a Test
Browser in which you may test Workshop web applications and web services.
When you run a web application or web service, the Test Browser
automatically loads Test View, a tool for exercising the application.
To start the debugger, click the Start button on the toolbar or press
Ctrl-F5. To pause debugging, click the Pause button on the toolbar. To stop
debugging, click the Stop button on the toolbar.
When the debugger is started, the WebLogic Workshop
Debugger command window is opened for the debugger proxy. This window
must remain open in order to use the debugger. If you close this window,
your breakpoints will not be hit when you test your application.
While your application is running in the debugger, it is unavailable to
clients other than the Test Browser.
To debug your project, you will use breakpoints, the commands that allow
you to navigate the code, and the debug windows, which show information
about variable values, how the program is running, and what code is
executed.
Breakpoints
Breakpoints allow you to halt execution at a specified point in the
program so you can observe information about its operation. When you halt
execution at a breakpoint, you can step through the program line-by-line,
step over a breakpoint, and use the debug windows to change values or
execute arbitrary code.
The types of breakpoints you can set include:
Line Breakpoints - halts execution at the line of code before the
breakpoint
Exception Breakpoints - halts execution when an exception occurs
Method Breakpoints - halts execution as soon as a specified method is
called
Taglib Breakpoints - halts at the taglib method being implemented
JSP Breakpoints - used with JSP files only
To create Exception and Method breakpoints, select Debug-->Create
Breakpoint and enter the appropriate settings in the Create
Breakpoint dialog.
To create a Line breakpoint, put the cursor on
the line of code where you want to halt execution and click the Toggle
Breakpoint button on the toolbar.
To clear all breakpoints at once including exception breakpoints in the
project, click the Clear All Breakpoints button on the toolbar, or press
Ctrl-F9.
Using the Debugging Commands
Once execution is halted on a breakpoint, you can use one of the
following commands to continue executing your code with the debugger. All of
these commands are available on the toolbar and on the Debug menu.
Step Into: The Step Into command continues execution
line-by-line, beginning with the next line of code. Use this command if
you want to debug your code one line at a time.
Step Over: The Step Over command executes a method call
without debugging that method, and halts execution on the next line. Use
this command if you know that the code in a method works and you don't
need to step into it.
Step Out: The Step Out command finishes executing a
method and returns execution to the procedure that called it, halting on
the line immediately following the method call. Use this command if you
have stepped into a method and you don't want to continue stepping all
the way through it.
Continue: The Continue command resumes execution until
another breakpoint is encountered or the procedure has completed.
Export Threads: The Export Threads command, found in
the Debug menu, creates and opens a text file that contains the call stacks
of all of the threads that are running. This is a convenient way to save or
share the current threads in the event of a deadlock or other threading
problem. The command is only active when the debugger has thread
information.
Note that if you step into a line that contains more than one statement, all
of the statements on that line will be executed when you step to the next
line.
Debug Windows
The debug windows provide information about values and conditions in your
code while you're running it in the debugger. There are several to choose
from:
Locals Window - shows variables that are in scope
Watch Window - displays the value of a specified variable while
debugging
Stream Window - shows output stream for JSPs
Immediate Window - allows you to execute code while debugging
Call Stack Window - shows the methods called to get to the point at
which execution halted
Threads Window - shows information about currently executing threads
Breakpoints Window - lists currently set breakpoints
To view one of the debug windows, choose Debug Windows from the View menu,
and select the desired window. For more detailed information about the debug
windows,
Debugging Properties
Several debugging options can be set on a project scope. The debugging
options for each project in an application are independent, and are not set
on an application basis.
Debugging properties for a project can be set on
the Project Properties dialog box. To change them, pull up the project
properties by either right-clicking the project folder in the
Application tab and selecting Properties from the
context menu, or by going to Tools-->ProjectProperties-->[Project_Name], then select
Debugger in the pane on the left.
Alternatively, project debugging properties can be set by editing the
WORK configuration file associated with the project.
Some project debugging properties apply only to specific types of
projects.
Smart Debugging
Smart debugging lets you focus on debugging your code and not platform
code. When you step through code, you stay in your own code. When smart
debugging is enabled, you can specify classes that the debugger will
automatically step through. Typically, the filtered classes are part of the
WebLogic Platform. For example, if you step into a method that's part of
WebLogic Server and that method eventually calls your own code, the debugger
will step directly into your code. For web application projects, this should
almost always be left on.
Smart debugging is enabled by default, and a default list of classes is
generated automatically. You can disable filtering on parts of the class
list by checking or unchecking the group of classes in the debugging
properties dialog. For example, if you uncheck XML classes, the debugger
will step into platform classes that support XML.
With version 8.1 SP2 or higher, you can add, remove, and edit the class
list. The asterisk (*) wildcard can be used to specify packages and
subpackages.
Build Before Debugging
This option specifies whether the project should be rebuilt before it is
run in the debugger. For web applications, only the current file is rebuilt
before running. For Java projects, the entire project is built before
running.
By default, the Build before debugging option is
enabled.
Pause All Threads After Stepping
This option specifies which threads are shown in the Threads window after
stepping in the debugger. All threads are always suspended after hitting a
breakpoint, but by default only the thread in which you are stepping is
visible. By default, this option is disabled to provide better performance,
so other threads will not be visible in the threads window. If you choose
not to suspend all threads after stepping, you can still view them on demand
using the Pause command.
Java and Control Project Options
Process Settings
The Create new process and Attach to process
radio buttons specify whether the debugger runs the application is run
locally or attaches to a remote process. These settings apply only to Java
and Control projects.
Create new process settings
When this option is selected, the debugger starts a new Java Virtual
Machine for the application when you click Start. The following options can
be set for this process:
Main class: The name of the class containing the
main method that is the entry point for
the application.
Parameters: Arguments that are passed to the
main method.
VM parameters: Arguments that are passed to the virtual
machine when it starts. These arguments may include
-D and -X
virtual machine options.
Home directory: The directory in which to start the
Java application.
Application classpath: Classpath used by the virtual
machine.
Automatically append Library JARs: When this option is
enabled, all of the JARs specified in the Libraries folder are appended
to the classpath.
Automatically append server classpath: Then this option
is enabled, all of the JARs that are specified in the"Default server
classpath" list in Tools-->WebLogic Server-->Server
Properties are appended to the classpath.
Attach to process
When this option is selected the debugger is attached to a specified Java
virtual machine that is already running and is configured to accept a
debugger when you click Start.
Socket: Connects to the virtual machine over the TCP/IP
connector. You must specify the port on which the VM is listening. If
blank, the server defaults to localhost.
Shared memory: Connects to the virtual machine over the
shared memory connector. You must specify the memory address on which
the VM is listening.
Debugging Scenarios
The WebLogic Workshop integrated debugger can be used in many debugging
scenarios, as listed in this topic.
Remote Debugging
If you're developing against a remote server, you can also debug against
that remote server. Breakpoints and other debugging information will be
stored on the local machine.
You can also debug on a managed server, as described below.
Debugging JSP Pages
Be aware that browser caching is always turned off when you are
debugging. To turn caching on while you are debugging, place the following
scriptlet in your JSP pages.
Note that browser caching is the default behavior when your web
application is deployed to a production server. You do not need to take
special measures, such as the scriptlet above, to turn on caching on a
production server.
Debugging EJBs
The debugger supports debugging EJBs regardless of whether they have been
developed within WebLogic Workshop. They can be debugged locally or
remotely.
Use the following procedure to attach the debugger to an EJB:
Open the source in Workshop
From the Tools menu choose Project Properties.
In the Debugger tab, choose Attach to Process.
Enter the debug port number (8453 by default) and server name or IP
address.
Click Start.
Set breakpoints as needed and start debugging.
Debugging on a Non-Workshop-Enabled Server
To debug a project on a server not configured as a Workshop Server, open
the Project Properties dialog box for the project you want to debug. On the
Debugger tab, choose the "Non Workshop Server" radio button, and enter the
debugging port number (8453 by default), the Http port number, and the name
or IP address of the remote server.
Debugging on a Managed Server
To debug a project on a managed server, set up the front end host and
port for the cluster and/or managed servers. Cluster servers can be set up
using a proxy. Run all of the managed servers except one, and the admin
server with nodebug on the start line. Do all of your debugging against the
managed server.
Debugging Unrunnable Files
Some files cannot be directly run by WebLogic Workshop; these include
servlets, custom Java controls, Java files, and so on. Nevertheless, you can
still set and hit breakpoints in these files. For example, to debug a
servlet, set breakpoints in the servlet source code, add a JSP page to your
project, run that JSP page (this will start the debugging process), and then
enter the servlet's URL directly into the browser's address bar. You will
now be able to halt at breakpoints in the servlet code.
To debug custom Java controls or Java files, set breakpoints in the
source code of those files, and then run a web service or some other
runnable file that calls into the Java control or Java file.
Starting Two Debugging Proxies in the Same Domain
If you start two server instances in the same domain (for example, using
the start up script
[BEA_HOME]/weblogic81/samples/domains/portal/startWebLogic.cmd), the second
server will fail with a TransportException.
ERROR: Proxy already running...
weblogic.debugging.comm.TransportException
at weblogic.debugging.comm.ServerConnectInfo.createTransport()Lweblogic.
debugging.comm.CommTransport;(ServerConnectInfo.java:63)
The failure is caused by the debugging proxy, which attempts to open the
same server socket port already used by the first server. To start the
second server running on a different port, send a port number parameter to
(1) the WebLogic Workshop IDE, (2) the server, and (3) the debugger. These
are described below.
To Set the Port Number on the WebLogic Workshop IDE
Add the following parameter to [BEA_HOME]\weblogic81\workshop\workshop.cfg.
-Dworkshop.debugProxyPort=PORT_NUMBER
To Set the Port Number on the Server
Add the following parameter to the server startup script (for example, [BEA_HOME]\weblogic81\samples\domains\workshop\startWebLogic.cmd/.sh).
-Dworkshop.debugProxyPort=PORT_NUMBER
To Set the Port Number on the Debugger Process
Add the following parameter to the server startup script (for example, [BEA_HOME]\weblogic81\samples\domains\workshop\startWebLogic.cmd/.sh).
-serverport=PORT_NUMBER
Testing Your Application
Testing your application goes hand-in-hand with debugging. The test facility
that comes with Weblogic Workshop runs in a browser window and is known as
Test View.
In addition to Test View, you can use JUnit for testing from within
Workshop.
Follow the links below for more information on using Test View and JUnit.
Share And Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
Keywords:
Debugging Your Application, WEBLOGIC, WebLogic, WebLogic tutorials, WebLogic tutorial pdf, history of WebLogic, How To Deploy An Application Using WebLogic , learn WebLogic
