AspectJ 5 supports several ways of enabling load-time weaving for an application: agents, a command-line launch script, and a set of interfaces for integration of AspectJ load-time weaving in custom environments.

The weaver is configured using one or more META-INF/aop.xml files located on the class loader search path. Each file may define a list of concrete aspects to be used for weaving, type patterns describing which types should woven, and a set of options to be passed to the weaver. In addition AspectJ 5 supports the definition of concrete aspects in XML. Aspects defined in this way must extend an abstract aspect visible to the weaver. The abstract aspect may define abstract pointcuts (but not abstract methods). The following example shows a simple aop.xml file:

          <aspectj>

            <aspects>
              <!-- declare two existing aspects to the weaver -->
              <aspect name="com.MyAspect"/>
              <aspect name="com.MyAspect.Inner"/>

              <!-- define a concrete aspect inline -->
              <concrete-aspect name="com.xyz.tracing.MyTracing"
                               extends="tracing.AbstractTracing"
                               precedence="com.xyz.first, *">
                <pointcut name="tracingScope" expression="within(org.maw.*)"/>
              </concrete-aspect>

              <!-- Of the set of aspects declared in this sole aop.xml,
                   use aspects matching the type pattern "com..*" for weaving. -->
              <include within="com..*"/>

              <!-- Of the set of aspects declared in this sole aop.xml,
                   do not use any aspects with the @CoolAspect annotation for weaving -->
              <exclude within="@CoolAspect *"/>

            </aspects>

            <weaver options="-verbose">
              <!-- Weave types that are within the javax.* or org.aspectj.*
                   packages. Also weave all types in the foo package that do
                   not have the @NoWeave annotation. -->
              <include within="javax.*"/>
              <include within="org.aspectj.*"/>
              <include within="(!@NoWeave foo.*) AND foo.*"/>
              <dump within="somepack.*"/><!-- will dump weaved classes to the "./_ajdump" folder on disk (for diagnostic purpose) -->
            </weaver>

          </aspectj>

		  

An aop.xml file contains two key sections: "aspects" defines one or more aspects to the weaver and controls which aspects are to be used in the weaving process; "weaver" defines weaver options and which types should be woven.

The simplest way to define an aspect to the weaver is to specify the fully-qualified name of the aspect type in an aspect element. You can also declare (and define to the weaver) aspects inline in the aop.xml file. This is done using the "concrete-aspect" element. A concrete-aspect declaration must provide a pointcut definition for every abstract pointcut in the abstract aspect it extends. This mechanism is a 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. Refer to the next section for more details.

The aspects element may optionally contain one or more include and exclude elements (by default, all defined aspects are used for weaving). Specifying include or exclude elements restricts the set of defined aspects to be used for weaving to those that are matched by an include pattern, but not by an exclude pattern. The within attribute accepts a type pattern of the same form as a within pcd, except that && and || are replaced by 'AND' and 'OR'.

Note that include and exclude affects the declared list of aspects (or concrete-aspect) defined in this sole aop.xml and has no side effect on other aop.xml files. Also note it is required to use aspect or concrete-aspect elements and that include does not mean "pick any aspect you 'll find" - as the aspect list must be known by the weaver.

The weaver element is used to pass options to the weaver and to specify the set of types that should be woven. If no include elements are specified then all types seen by the weaver will be woven.

When several configuration files are visible from a given weaving class loader their contents are conceptually merged (this applies to both aop.xml files and to aop.properties files as described in the next section). The files are merged in the order they are found on the search path (regular getResourceAsStream lookup) according to the following rules:

It is not an error for the same aspect to be defined to the weaver in more than one visible META-INF/aop.xml file. However, if a declarative concrete aspect is declared in more than aop.xml file then an error will be issued. A concrete aspect defined in this way will be used to weave types loaded by the class loader that loaded the aop.xml file in which it was defined.

A META-INF/aop.xml file will automatically be generated when using the -outjar option of the AspectJ compiler. It will simply contain a (possibly empty) set of aspect elements, one for each concrete aspect included in the JAR.

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, and also gives control over precedence through the precedence attribute of the concrete-aspect XML element. Consider the following:

            package mypack;

            @Aspect
            public abstract class AbstractAspect {

                // abstract pointcut: no expression is defined
                @Pointcut
                abstract void scope();

                @Before("scope() && execution(* *..doSome(..))")
                public void before(JoinPoint jp) {
                   ....
                }
            }
            

This aspect is equivalent to the following in code style:

            package mypack;

            public abstract aspect AbstractAspect {

                // abstract pointcut: no expression is defined
                abstract pointcut scope();

                before() : scope() && execution(* *..doSome(..)) {
                   ....
                }
            }
            

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:

            <aspectj>
                <conrete-aspect name="mypack.__My__AbstractAspect" extends="mypack.AbstractAspect">
                    <pointcut name="scope" expression="within(yourpackage..*)"/>
                </concrete-aspect>
            </aspectj>
            

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:

                // exception handling omitted
                Class myConcreteAspectClass = Class.forName("mypack.__My__AbstractAspect");

                // here we are using a singleton aspect
                AbstractAspect concreteInstance = Aspects.aspectOf(myConcreteAspectClass);
            

As described in the previous section, the concrete-aspect element in META-INF/aop.xml gives the option to declare the precedence, just as @DeclarePrecedence or declare precedence do in aspect source code.

Sometimes it is required to declare precedence without extending any abstract aspect as well. For such a need, it is possible to use the concrete-aspect element without the extends attribute and without any pointcut nested element, but only with a precedence attribute. Consider the following:

                <aspectj>
                    <concrete-aspect name="mypack.__MyDeclarePrecedence"
                                     precedence="*..*Security*, Logging+, *"/>
                </aspectj>
            

This deployment time declaration is only defining a precedence rule. You have to remember that the name attribute must be a valid fully qualified class name that will be then reserved for this concrete-aspect and must not conflict with other classes you deploy.

The table below lists the AspectJ options supported by LTW. All other options will be ignored and a warning issued.