XWeaver
This page introduces the XWeaver aspect weaver that is used to process aspect programs written in the AspectX language. XWeaver is built as a sequence of XSL programs that must be applied in succession to the AspectX program and to the srcML representation of the base code. Its output is the srcML representation of the modified code (see also the description of the XWeaver weaving approach). The structure of XWeaver is as shown in the figure:
Figure 1: XWeaverStructure_1
XWeaver consists of three components - the compiler, the locator and the weaver - and a set of weaving rules. Additionally, during the weaving process it produces an annotated version of the base code. This architecture was chosen primarily because it promotes extensibility and customizability. In some cases, however, it led to the implementation of solutions that are less efficient or less effective than they might otherwise be.
As was already noted, given that both the input (the base code) and the output (the modified code) of XWeaver are encoded in XML, one could dispense with a dedicated aspect language and write the aspect program directly in XSL. This however would require users to be proficient in XSL and to have an intimate knowledge of the structure of the srcML representation of the base code. The alternative solution would have been to define a new aspect language totally independent of the representation used for the base code. In fact, in the latter case, one might have used one of the existing aspect languages for C++ such as AspectC++. The XWeaver project chose an intermediate solution where a new language - AspectX - is defined but this language is not entirely decoupled from the srcML language. The coupling between the two languages is most evident in the way pointcuts and code modifiers are modelled in AspectX.
Since both the base code and the modified code are encoded in XML, then the best way to implement a weaver is as an XML program. If the first route had been selected - no aspect language of any kind - then the XSL program would have served as both the weaver and the aspect program. If, on the other hand, a new aspect language had been defined completely independent of srcML, then the most natural architecture for the weaver would have been to implement it as a compiler that translate the aspect specification expressed in the aspect language to an equivalent XSL program that can weave the aspect on the base code. The intermediate character of the solution adopted in the XWeaver project is reflected in the XWeaver architecture that includes a compilation stage but also includes some additional processing stages.
The purpose of the XWeaver compilation stage is to translate the aspect program written in AspectX into an XSL program called the
locator. An aspect program in general consists of two parts: the specification of a set of locations in the base
code (expressed through pointcuts) and a specification of the code to be inserted at these locations (expressed through advices). XWeaver
separates the treatment of these two parts of the aspect program and the locator is only concerned with the former part, namely with
the identifications of the locations in the code where changes are required. More precisely, the locator is a program that, based on the
pointcut information in the AspectX program, transforms the base code by adding to it a set of annotations.
The annotations are XML advice elements that are placed at the points in the base code where a code change may be required.
The annotated base code produced by the locator program thus contains all the
information present in the base code and adds to it the code change location information. From the point of view of the XWeaver,
the base code and the aspect program can be discarded after the annotated base code has been produced. As an example of an annotation consider the following:
<function> <...> <block>{
<return>
<advice name="checkBeforeReturn" type="before">
<codeModifier type="codeFragment">
<text>if( battery == 0 ) {</text>
<text> recoveryAction.recover();</text>
<text>}</text>
</codeModifier>
</advice>
return <expr><name>battery</name></expr>;</return>
}</block></function>
The annotated base code helps to separate the treatment of the pointcuts from the treatment of the advices. The generation of the annotated base code by the locator program only requires knowledge about the pointcuts whereas the processing of the annotated base code by the weaver only requires knowledge of the advices. This separation makes for a simpler structure of both the locator and the weaver.
The basic task of the locator is to resolve each pointcut and then to identify the locations in the base code that are specified by the pointcut. It should be stressed that this task cannot be performed by a general purpose XSL program because the pointcuts in AspectX are specified using terms that belong to the srcML language (see the discussion of the coupling between AspectX and srcML). This is the reason why a compilation phase is required.
The weaving of the modifications specified by the aspect program into the base code is performed by the weaver component of the XWeaver tool. The weaver is implemented as an XSL program. In pursuit of the two goals of extensibility and customizability, the weaving is organized as the application of weaving rules to the annotated base code. The weaver program is very simple and its purpose is to inspect the annotated base code and, whenever an annotation is found, to determine which aspect defines the transformation to be performed at that point in the code and then to call the appropriate weaving rule that will insert the new code in the base code.
A weaving rule defines a code transformation as a function of the following triplet:
At each annotation in the base code, the weaver determines the value of the triplet and then calls the corresponding weaving rules which is responsible for weaving the new code in the base code. Weaving rules are implemented as self-contained XSL programs and each weaving rule is stored in a dedicated file. XWeaver provides a set of predefined weaving rules but users are free to add new ones or to modify the library of default rules. Changes to the weaving rules have no impact on the rest of the XWeaver tool. This guarantees both the extensibility and the customizability of XWeaver. Extensibility is achieved by allowing users to add new rules that implement new kinds of transformations and customizability is achieved by allowing users to modify the default rules thus allowing them to tailor the way aspects are woven into the base code.
Currently, XWeaver provides default rules to handle the following triplets:
| src:block | around | codeFragment |
| src:block | begin | codeFragment |
| src:block | end | codeFragment |
| src:comment | end | comment |
| src:comment | replace | codeFragment |
| src:constructor | begin | codeFragment |
| src:constructor | end | codeFragment |
| src:function_decl, src:function, src:class, src:constructor, src:constructor_decl, src:constructor, src:destructor, src:destructor_decl, src:decl_stmt | add | comment |
| src:expr | replace | codeFragment |
| src:function | begin | codeFragment |
| src:function | end | codeFragment |
| src:name | replace | codeFragment |
| src:return | before | codeFragment |
| src:return | replace | codeFragment |
| src:unit | add | comment |
C/C++ specific rules
| accessModifierBlock (src:public, src:private, src:protected) | add | declaration |
| src:class | add | accessModifierBlock |
| src:class | add | declaration |
| src:constructor | add | initializer |
| src:memberList | add | initializer |
| src:unit | add | declaration |
| src:unit | add | definition |
| src:unit | add | include |
Java specific rules
| src:class | add | member |
| src:unit | add | import |