AspectWerkz Pattern Language

Join point selection pattern language

AspectWerkz support a fine-grained pattern language for picking out join points.


You can utilize two types of wildcards when constructing your patterns:

* - which is used as a regular wildcard. Matches for example only one package level or one method parameter. When used to match a package name, matches at least one character. Else match zero or more character.

.. - used either to match any sequence of characters that start and end with a "." (so it can be used to pick out all types in any subpackage) or in method selectors to match as many parameters as possible.

For example org.codehaus..* will match all classes in all subpackages starting from org.codehaus.

* method(..) will match all methods with any number of parameters.
Note: you can only use the .. wildcard as the "last" thing specified. I.e. this is not possible:, but this is: The same thing holds for method parameters.

Another specific character to express inheritance based matching will be presented further.

Combining the patterns

The patterns normally consists of a combination of a class and a method pattern or a class and a field pattern.

Example of a full method pattern:

<annotations> <modifiers> <return_type_pattern> <package_and_class_pattern>.<method_name_pattern>(<parameter_type_patterns>)

Example of a full field pattern:

<annotations> <modifiers> <field_type_pattern> <package_and_class_pattern>.<field_name_pattern>

Example of a full class pattern:

<annotations> <modifiers> <package_and_class_pattern>

Class selections

The classes are selected by specifying a pattern that consists of:

All class patterns must follow this structure:

<annotations> <modifiers> <full_class_name>

For the class selections specify the full package name of the class along with some wildcards.







Method selections

The methods are selected by specifying a pattern that consists of:

All method patterns must follow this structure:

<annotations> <modifiers> <return_type> <full_method_name>(<parameter_types>)


int foo.*.Bar.method()

int *.method(*)

* method(..)

int foo.*.*.method(*,int)

int foo.*.Bar.method(..)

int foo.*.Bar.method(int,..)

int foo.*.Bar.method(java.lang.*)

int foo.**o*()

* foo.*.Bar.method()

java.lang.* foo.*.Bar.method()

static int foo.*.Bar.method()

@Transaction * foo.*.*.*(..)

Constructor selections

The constructors are selected by specifying a pattern that consists of:

All the patterns must follow this structure:

<annotations> <modifiers> <className>.new(<parameter_types>)

DSO is not using constructor selectors and to match on constructors you should use method selector for __INIT__ method instead. So instead of use * Foo.__INIT__(..)



* new(..)


Field selections

Fields are selected by specifying a pattern that consists of:

All field patterns must follow this structure:

<annotations> <modifiers> <field_type> <full_field_name>

Note that DSO currently doesn't support selection of excluded or transient fields based on annotations.


int foo.*.Bar.m_foo

* m_field

* foo.*.Bar.m_foo

java.lang.* foo.*.Bar.m_foo

int foo.*.Bar.m_*

int foo.*.Bar.m_*oo*

Subtype patterns

It is possible to pick out all subtypes of a type with the "+" wildcard. The "+" wildcard follows immediately a type name pattern. So, while

* foo.Bar.*(..)

picks out all method call join points where an instance of exactly type Foo is constructed,

* foo.Bar+.*(..)

picks out all method call join points where an instance of any subtype of Foo (including Foo itself) is constructed.

Note that in the previous sample, foo.Bar can be wether a class (a super class) or an interface.

Array type patterns

A type name pattern or subtype pattern can be followed by one or more sets of square brackets to make array type patterns. So java.lang.Object[] is an array type pattern, and so is*[][].


When picking out the return and parameter types it is possible to use predefined abbreviations for the classes in the java.lang.* and java.util.* packages. If you specify only the class name it will be mapped to the full class name for the class (you cannot use patterns in abbreviations).

Abbreviations are supported for array types as well, with a dimension less or equal to 2. String[][] will thus be resolved as java.lang.String[][] but String[][][] will not.

This is usefull when dealing with complex advice signature in the XML definition.


You can use:

Apart from these abbreviations you always have to specify the fully qualified name of the class (along with the wildcards).