The WebLogic Workshop integrated debugger can be used in many debugging scenarios, as listed in this topic.
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. For more information on pointing to a remote server, see How Do I: Use a Remote WebLogic Server During Development?
For more information on debugging on a remote server, see How Do I: Debug an Application on a Remote Production Server?
You can also debug on a managed server, as described below.
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.
<% response.setHeader( "Cache-Control", null ); %>
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.
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:
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.
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.
For more information about managed servers, see Managed Servers and Clustered Managed Servers.
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.
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.
Add the following parameter to [BEA_HOME]\weblogic81\workshop\workshop.cfg.
-Dworkshop.debugProxyPort=PORT_NUMBER
Add the following parameter to the server startup script (for example, [BEA_HOME]\weblogic81\samples\domains\workshop\startWebLogic.cmd/.sh).
-Dworkshop.debugProxyPort=PORT_NUMBER
Add the following parameter to the server startup script (for example, [BEA_HOME]\weblogic81\samples\domains\workshop\startWebLogic.cmd/.sh).
-serverport=PORT_NUMBER
How Do I: Debug a Java Project?
How Do I: Debug an Application?
How Do I: Debug an Application on a Remote Production Server?