Red Hat Web Application Framework 6.1 Manuale Utente

WAF Debugging Setup

In

Eclipse, select Run =



Debug. In the dialog box, select Remote Java Application and then

click on

New. Then enter information for the following tabs:

•

Connect Tab
Enter a name for your debug configuration, such as

webapp-debug

. Select the same project

previously selected as the main project. Enter the host name (

localhost

should be fine). Use

8000

as your connection port. Also, select

Allow termination of remote VM.

•

Source Tab
Add all the external JARs under

$RESIN_HOME/lib

to your source lookup path.

•

Common Tab
At the bottom of the dialog box, select

Display in favorites menu: Debug.

You are now finished and may close the dialog box.

Your

Eclipse setup should now be complete. To test this:

1. Select

Run =



External Tools =



[Deploy Script].

2. Select



Run and pick the WAF configuration. The server’s log output should become

visible in the

Console. Wait for the server to finish initializing.

3. Select

Run =



Debug and pick the debug configuration. This opens the Debug perspective.

Open a source file, set a breakpoint, and request a page from the server.

If everything is setup correctly, you can now develop with

Eclipse and use it to step through your

WAF code.

When code breaks, there are two ways to figure out what went wrong: launch a debugger and step

through the program, or add logging statements to see what is going on. In its crudest form, logging

means adding a few

System.err.println()

calls here and there. What are the benefits of logging

over using a debugger?

The Practice of Programming by Brian W. Kernighan and Rob Pike
As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable

or two. One reason is that it is easy to get lost in details of complicated data structures and control flow;

we find stepping through a program less productive than thinking harder and adding output statements and

self-checking code at critical places. Clicking over statements takes longer than scanning the output of

judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to

the critical section of code, even assuming we know where that is. More important, debugging statements

stay with the program; debugger sessions are transient.

Another important use of logging is to provide an audit trail: who did what and when. The predominant

pattern in WAF is to write such auditing information to the database rather than the filesystem. The

logging framework in WAF is intended to be used primarily for troubleshooting and debugging.