7:53 a.m.
Author: pete.muir(a)jboss.org
Date: 2009-07-25 08:53:11 -0400 (Sat, 25 Jul 2009)
New Revision: 3213
Modified:
tck/trunk/doc/reference/en-US/eclipse-debugging.xml
Log:
use xref, ws
Modified: tck/trunk/doc/reference/en-US/eclipse-debugging.xml
===================================================================
--- tck/trunk/doc/reference/en-US/eclipse-debugging.xml 2009-07-25 12:47:33 UTC (rev
3212)
+++ tck/trunk/doc/reference/en-US/eclipse-debugging.xml 2009-07-25 12:53:11 UTC (rev
3213)
@@ -2,17 +2,22 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
<chapter id="eclipse-debugging">
<title>Debugging Tests in Eclipse</title>
- <para>This chapter explains how to debug standalone tests and integration
+ <para>
+ This chapter explains how to debug standalone tests and integration
tests from the TCK test suite in Eclipse. You should be able to use the
- lessons learned here to debug tests in an alternate IDE.</para>
+ lessons learned here to debug tests in an alternate IDE.
+ </para>
<section>
<title>Debugging a standalone test</title>
- <para>There is almost no difference in how you debug a standalone test
+ <para>
+ There is almost no difference in how you debug a standalone test
from how you run it. With the test class open in the Eclipse editor,
simply right click in the editor view and select TestNG > Debug as
test. Eclipse will stop at any breakpoints you set just like it would
- with any other local debug process.</para>
- <para>If you plan to step into a class in a Web BEans implementation (or
+ with any other local debug process.
+ </para>
+ <para>
+ If you plan to step into a class in a Web Beans implementation (or
any other dependent library), you must ensure that the source is
properly associated with the library. Below are the steps to follow to
associate the source of the Web Beans with the TestNG debug
@@ -20,57 +25,81 @@
</para>
<orderedlist>
<listitem>
- <para>Select the Run > Debug Configurations... menu from the
main
- menubar</para>
+ <para>
+ Select the Run > Debug Configurations... menu from the main
+ menubar
+ </para>
</listitem>
<listitem>
- <para>Select the name of the test class in the TestNG category
+ <para>
+ Select the name of the test class in the TestNG category
</para>
</listitem>
<listitem>
- <para>Select the Source tab</para>
+ <para>
+ Select the Source tab
+ </para>
</listitem>
<listitem>
- <para>Click the Add... button on the right</para>
+ <para>
+ Click the Add... button on the right
+ </para>
</listitem>
<listitem>
- <para>Select Java Project</para>
+ <para>
+ Select Java Project
+ </para>
</listitem>
<listitem>
- <para>Check the project the contains the class you want to debug
- (e.g., webbeans-core)</para>
+ <para>
+ Check the project the contains the class you want to debug
+ (e.g., webbeans-core)
+ </para>
</listitem>
<listitem>
- <para>Click OK on the Project Selection window</para>
+ <para>
+ Click OK on the Project Selection window
+ </para>
</listitem>
<listitem>
- <para>Click Close on the Debug Configurations window</para>
+ <para>
+ Click Close on the Debug Configurations window
+ </para>
</listitem>
</orderedlist>
- <para>You'll have to complete those steps for any test class you
are
+ <para>
+ You'll have to complete those steps for any test class you are
debugging, though you only have to do it once (the debug configuration
- hangs around indefinitely).</para>
- <para>Again, running a test in standalone isn't enough to pass the
- TCK and cannot be used to run or debug an integration test. Let's
- look at how to debug a test running in the context of the container.
+ hangs around indefinitely).
</para>
+ <para>
+ Again, running a test in standalone isn't enough to pass the TCK and
+ cannot be used to run or debug an integration test. Let's look at how
+ to debug a test running in the context of the container.
+ </para>
</section>
<section>
<title>Debugging an integration test</title>
- <para>In order to debug an integration test, or any test run in
- in-container mode, the test must be configured to run in-container, as
- described in section 6.4, and you must attach the IDE debugger to the
- container. That puts the debugger on both sides of the fence, so to
- speak.</para>
- <para>Since setting up a test to run in-container has already been
- covered, we'll look at how to attach the IDE debugger to the
- container, and then move on launching the test in debug mode.</para>
+ <para>
+ In order to debug an integration test, or any test run in in-container
+ mode, the test must be configured to run in-container, as described in
+ <xref linkend="eclipse-in-container" />
+ , and you must attach the IDE debugger to the container. That puts the
+ debugger on both sides of the fence, so to speak.
+ </para>
+ <para>
+ Since setting up a test to run in-container has already been
+ covered, we'll look at how to attach the IDE debugger to the container,
+ and then move on launching the test in debug mode.
+ </para>
<section>
<title>Attaching the IDE debugger to the container</title>
- <para>There are two ways to attach the IDE debugger to the container.
+ <para>
+ There are two ways to attach the IDE debugger to the container.
You can either start the container in debug mode from within the
IDE, or you can attach the debugger over a socket connection to a
- standalone container running with JPDA enabled.</para>
+ standalone container running with JPDA enabled.
+ </para>
<para>
The Eclipse Server Tools, a subproject of the Eclipse Web Tools
Project (WTP), has support for launching most major application
@@ -102,10 +131,12 @@
hits the breakpoint this time, it halts the JVM thread of the
container rather than the thread that launched the test.
</para>
- <para>Remember that if you need to debug into dependent libraries, the
+ <para>
+ Remember that if you need to debug into dependent libraries, the
source code for those libraries needs to be registered with the
TestNG debug configuration as described in the first section in this
- chapter.</para>
+ chapter.
+ </para>
</section>
</section>
</chapter>