From aa8a1d26e3080ba37115ffb3bbadce5d2fef6cc0 Mon Sep 17 00:00:00 2001 From: aclement Date: Thu, 13 May 2010 18:25:34 +0000 Subject: [PATCH] m2 updates --- docs/dist/doc/README-169.html | 50 +++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/docs/dist/doc/README-169.html b/docs/dist/doc/README-169.html index 7e1e5d940..c75809478 100644 --- a/docs/dist/doc/README-169.html +++ b/docs/dist/doc/README-169.html @@ -20,6 +20,56 @@ All rights reserved.

AspectJ 1.6.9 Readme

+

Features of 1.6.9 milestone 2

+ +

Mostly bug fixes, some important fixes around the use of Method ITDs with private fields + (bug 307120)

+ +

Transparent weaving: 309743

+

In a further step towards transparent weaving, support for the AjType reflection system is now being made optional. +This means if intending to use the AjTypeSystem to reflect on woven code, then the code must be built with the +option -makeAjReflectable. This change is being made because the reflection supporting metadata that +enables the AjTypeSystem to work can break other tools that are just using regular reflection on the classes. These +days many more users are processing classes using standard reflection than are using AjTypeSystem. The related bugzilla +discussing this issue is 309743.

+ +

Overweaving: 293450

+ +

Preliminary support for overweaving was added in AspectJ 1.6.7, but now in AspectJ 1.6.9m2 it is much more reliable. +Basically it is an alternative to reweaving when needing to weave a class multiple times. Overweaving can cope with +'other tools' modifying the bytecode in between AspectJ weaves, whereas reweaving cannot. More details are in the related +bugzilla 293450 and in this +blog article. A weaver is switched +into overweaving mode by the option -Xset:overWeaving=true - which can be specified on the command line or in the weaver +options section of aop.xml. There is still more work to be done on this feature - any feedback is welcome.

+ +

AOP Scoping: 124460

+ +

Another feature that had preliminary support a while ago is aspect scoping in aop.xml. This has also been improved in +AspectJ1.6.9m2. For those not aware of it, it is the ability to specify a scope against aspects defined in your loadtime +weaving aop.xml file. A scope effectively enables the user to limit the applicability of your aspect to some subset of all those +types included by the weaver include section. Why is it needed? It can be useful when taking an aspect that did not +originally scope itself properly (using a within clause) and needing to limit its effect in a load time weaving context. + Think of it as a within +pattern that you can put into the aop.xml that augments all the pointcuts defined in the original aspect.

+ +

Here is an example:

+
+<aspectj>
+  <aspects>
+    <aspect name="X"/>
+    <aspect name="Y" scope="com.foo..*"/>
+  </aspects>
+  <weaver>
+    <include within="com..*"/>
+  </weaver>
+</aspectj>
+
 +

In this example the weaver include section specifies all the types in com..* should be woven and the +aspects to be used are X and Y. The new 'scope' setting on aspect Y's definition allows finer control, and specifies that +Y should in fact only be applied to com.foo..* types.

+ +

Features of 1.6.9 milestone 1

Message inserts for declare warning/error messages

-- 2.39.5