From 38af9949c6ffd1b07aaab3271cd57f83ce247286 Mon Sep 17 00:00:00 2001
From: wisberg <wisberg>
Date: Fri, 3 Nov 2006 07:47:16 +0000
Subject: to pdguide added XLint list, more control options, debugging
 pointcuts, and more hand-holding.

---
 docs/pdGuideDB/ltwdump.xml | 55 ++++++++++++++++++++++------------------------
 1 file changed, 26 insertions(+), 29 deletions(-)

(limited to 'docs/pdGuideDB/ltwdump.xml')

diff --git a/docs/pdGuideDB/ltwdump.xml b/docs/pdGuideDB/ltwdump.xml
index 36b1bea3a..049f2e4f5 100644
--- a/docs/pdGuideDB/ltwdump.xml
+++ b/docs/pdGuideDB/ltwdump.xml
@@ -1,38 +1,35 @@
-<chapter id="ltwdump" xreflabel="LTW Dump">
-    <title>LTW Dump</title>
+<chapter id="ltwdump" xreflabel="Dumping classes during load-time weaving">
+    <title>Dumping classes during load-time weaving</title>
     
     <sect1 id="ltwdump-introduction">
         <title>Introduction</title>
         
-        <para> Occasionally problems may be encountered with classes that have been load-time woven. 
-        Symptoms will include incorrect program function or a Java exception such as 
-        <literal>java.lang.VerifyError</literal>. Problems can be caused by the way 
-        an aspect or class is built, incompatibilities between AspectJ and 
-        generated byte-code 
-        e.g. <ulink url="https://bugs.eclipse.org/bugs/show_bug.cgi?id=117854">CGLIB</ulink>
-        or a bug in the weaver.
-        When these problems occur it may be necessary to attach the class files concerned
-        to a bug report. AspectJ can be configured to dump byte-code to disk using
-        <literal>META-INF/aop.xml</literal>. The <literal>_ajdump</literal> subdirectory the the current
-        working directory is used. </para>
-    
-        <sect2 id="configuration" xreflabel="configuration">
-            <title>Configuration</title>
-            
-            <para> See the 
+        <para> 
+            Very rarely, problems present not at build-time but at run-time,
+            with <literal>java.lang.VerifyError</literal> or incorrect behavior.
+            In these situations, it's most helpful to include the offending class 
+            in the bug report.  But with load-time weaving, the woven classes are 
+            in memory only; to save classes woven at load-time, configure
+            <literal>META-INF/aop.xml</literal> to dump the classes (by default 
+            to an <literal>_ajdump</literal> subdirectory of the current working 
+            directory).  Also, if the input class file is not available (e.g., if
+            the AspectJ weaver is after another bytecode weaver), you can
+            also configure the weaver to dump the input classes.
+        </para>
+        <sect2 id="ltw-examples" xreflabel="ltwdump-configuration">
+            <title>Configuring bytecode dumping in load-time weaving</title>
+            <para>
+  			For details of how to configure byte-code dumping, see the             
+            AspectJ Development Environment Guide section on 
 				<ulink url="../devguide/ltw-configuration.html#configuring-load-time-weaving-with-aopxml-files">
-				Development Environment Guide</ulink>
-  				for details of how to configure byte-code dumping. </para>
-  		</sect2>
+				Configuring Load-time Weaving</ulink>.  
+            Following is a simple example.
+            </para>
+            </sect2>
 
-        <sect2 id="examples" xreflabel="examples">
-            <title>Examples</title>
-        
-            <para> By default AspectJ will dump byte-code only after it is woven. This 
-            is because usually the original class file is already available. However 
-            byte-code is sometimes generated by frameworks or downloaded over the network
-            in which case AsepctJ can dump the byte-code before it is woven too. </para>
-            
+        <sect2 id="ltwdump-examples" xreflabel="LTW Dump Examples">
+            <title>LTW Dump Examples</title>
+                    
             <para> The following <literal>META-INF/aop.xml</literal> will 
             weave classes in the <literal>com.foo</literal> package (and subpackages) but not
             CGLIB generated classes in the <literal>com.foo.bar</literal> package (and subpackages). 
-- 
cgit v1.2.3