summaryrefslogtreecommitdiffstats
path: root/docs/faq/faq.xml
diff options
context:
space:
mode:
authoraclement <aclement>2008-06-11 00:56:43 +0000
committeraclement <aclement>2008-06-11 00:56:43 +0000
commit27e794ebf410b678643cd079a1b9a285774b46e8 (patch)
tree63019645810dbb71f0562cf1016f916008d9282d /docs/faq/faq.xml
parent15417326c953d13c906f3e7d516fcf64ed04d36a (diff)
downloadaspectj-27e794ebf410b678643cd079a1b9a285774b46e8.tar.gz
aspectj-27e794ebf410b678643cd079a1b9a285774b46e8.zip
faq update for 160146
Diffstat (limited to 'docs/faq/faq.xml')
-rw-r--r--docs/faq/faq.xml31
1 files changed, 31 insertions, 0 deletions
diff --git a/docs/faq/faq.xml b/docs/faq/faq.xml
index 1d0338384..05ddbc903 100644
--- a/docs/faq/faq.xml
+++ b/docs/faq/faq.xml
@@ -3844,6 +3844,37 @@ aspect A {
</para>
</answer>
</qandaentry>
+ <qandaentry>
+ <question id="q:weavingcglib"
+ xreflabel="Q:I get a VerifyError when running CGLIB generated code that has been woven by AspectJ. Why is this?">
+ <para>I get a VerifyError when running CGLIB generated code that has been woven by
+ AspectJ. Why is this?
+ </para>
+ </question>
+ <answer>
+ <para>When weaving after advice into any piece of code, the AspectJ strategy is to make all
+ exit points from that code jump to a single exit point that executes the advice
+ before returning. There is a verifier rule in the JVM specification that specifies
+ that all routes to a jump destination must have the same height stack when they get there,
+ regardless of the route taken to get there through the bytecode. The CGLIB generated code has different
+ stack heights at the various exit points. This is not a problem with the CGLIB generated code,
+ it is perfectly valid - it is just unusual and the AspectJ weaving strategy causes the
+ verify error to trigger when it makes all exits jump to a single destination.
+ </para>
+ <para>AspectJ could cope with this and instead implement after advice by calling the
+ advice and returning at each exit point. However, it is unlikely that the user
+ actually meant to weave the CGLIB generated code in the first place - and so usually
+ the right thing to do is to exclude CGLIB generate code from the weaving process by
+ appropriate use of the exclude element in the aop.xml. A typical clause in the aop.xml might
+ look as follows:
+ </para>
+ <programlisting>
+&lt;weaver&gt;
+ &lt;exclude within="*CGLIB*" /&gt;
+&lt;/weaver&gt;
+ </programlisting>
+ </answer>
+ </qandaentry>
</qandadiv>
<qandadiv id="aj11" xreflabel="AspectJ 1.1 and eclipse.org">