From 76ebbc76add2abd815b3a8b5ea0beb11c94c8c49 Mon Sep 17 00:00:00 2001 From: avasseur Date: Tue, 25 Oct 2005 10:00:58 +0000 Subject: concrete-aspect impl and doc for LTW - see #95529 pbly some issue on abstract @Pointcut() in ajdt core - fix coming --- docs/devGuideDB/ltw.xml | 96 ++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 88 insertions(+), 8 deletions(-) (limited to 'docs/devGuideDB') diff --git a/docs/devGuideDB/ltw.xml b/docs/devGuideDB/ltw.xml index b0abbf37a..09ac6520c 100644 --- a/docs/devGuideDB/ltw.xml +++ b/docs/devGuideDB/ltw.xml @@ -39,8 +39,8 @@ need to specify the -Xreweavable compiler option when building them. This causes AspectJ to save additional state in the class files that is used to support subsequent reweaving. - As per AspectJ 1.5.0 M3 aspects (code style or annotation style) are - reweavable by default, and weaved classes may be as well in 1.5.0 final. + As per AspectJ 1.5.0 M3 aspects (code style or annotation style) are + reweavable by default, and weaved classes are reweavable by default as well as per AspectJ 1.5.0 M4. @@ -206,12 +206,7 @@ useful way of externalizing configuration for infrastructure and auxiliary aspects where the pointcut definitions themselves can be considered part of the configuration of the service. - - - - - Note: concrete-aspect is not available in AspectJ 1.5 M3. - + Refer to the next section for more details. @@ -272,6 +267,91 @@ each concrete aspect included in the JAR. + + Using Concrete Aspects + + It is possible to concretize an abstract aspect by the mean of the META-INF/aop.xml + file. This is usefull to define abstract pointcuts at deployment time. + Consider the following: + + + + This aspect is equivalent to the following in code style: + + + + This aspect (in either of its style) is a good candidate for concretization through META-INF/aop.xml. + It defines the abstract pointcut within(). It is important to remember that + concretization in this case must obey to the following rules: + + The parent aspect must be abstract. It can be an @AspectJ or a + regular code style aspect. + Only simple abstract pointcut can be concretized ie pointcut that don't expose + state (through args(), this(), target(), if()). In @AspectJ syntax + as illustrated in this sample, this means the method that hosts the pointcut is abstract, + has no arguments, and returns void. + Concretization must defines all such abstract pointcuts ie it is not possible + to have concrete-aspect inter dependancies. + Concretization can only concretize pointcuts ie there cannot be abstract method + left in the aspect. + + If you have requirements for more complex aspect inheritance, you should consider regular aspect + inheritance instead of concretization through XML. + Given that the following XML is valid: + + + + + + + ]]> + + It is important to remember that the name attribute in the XML directive + concrete-aspect defines the fully qualified name that will be given to the + concrete aspect. It must then be a valid class name. This one will indeed be generated on the fly by the weaver internals. You must + then ensure that there won't be name collision. Also note that the concrete aspect will be + defined at the classloader level for which the aop.xml is visible. This implies that if you need + to use the aspectof methods to access the aspect instance(s) (depending on the perclause + of the aspect it extends) you have to use the helper API org.aspectj.lang.Aspects.aspectOf(..) + as in: + + + +