/usr/share/doc/aspectj-doc/devguide/ltw-configuration.html is in aspectj-doc 1.8.9-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Configuration</title><link rel="stylesheet" type="text/css" href="aspectj-docs.css"><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"><link rel="home" href="index.html" title="The AspectJtm Development Environment Guide"><link rel="up" href="ltw.html" title="Chapter 5. Load-Time Weaving"><link rel="prev" href="ltw-rules.html" title="Load-time Weaving Requirements"><link rel="next" href="ltw-specialcases.html" title="Special cases"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Configuration</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ltw-rules.html">Prev</a> </td><th width="60%" align="center">Chapter 5. Load-Time Weaving</th><td width="20%" align="right"> <a accesskey="n" href="ltw-specialcases.html">Next</a></td></tr></table><hr></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ltw-configuration"></a>Configuration</h2></div></div></div><p>New in AspectJ 5 are a number of mechanisms to make load-time weaving
easy to use. The load-time weaving mechanism is chosen through JVM startup options.
Configuration files determine the set of aspects to be used for weaving and which
types will be woven. Additional diagnostic options allow the user to debug the configuration and
weaving process. </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="enabling-load-time-weaving"></a>Enabling Load-time Weaving</h3></div></div></div><p> 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. </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Agents</span></dt><dd><p>AspectJ 5 ships with a number of load-time weaving agents that
enable load-time weaving. These agents and their configuration
are execution environment dependent. Configuration for the supported environments is discussed
later in this chapter.</p><p>
Using Java 5 JVMTI you can specify the <code class="literal">-javaagent:pathto/aspectjweaver.jar</code> option
to the JVM.</p><p>
Using BEA JRockit and Java 1.3/1.4, the very same behavior can be obtained using BEA JRockit JMAPI features with
the <code class="literal">-Xmanagement:class=org.aspectj.weaver.loadtime.JRockitAgent</code>
</p></dd><dt><span class="term">Command-line wrapper scripts <code class="literal">aj</code></span></dt><dd><p>The <span class="command"><strong>aj</strong></span> command runs Java programs in Java 1.4 or
later by setting up <code class="literal">WeavingURLClassLoader</code> as the
system class loader.
For more information, see <a class="xref" href="aj-ref.html#aj" title="Description">aj</a>.
</p><p>The <span class="command"><strong>aj5</strong></span> command runs Java programs in Java 5
by using the <code class="literal">-javaagent:pathto/aspectjweaver.jar</code> option
described above.
For more information, see <a class="xref" href="aj-ref.html#aj" title="Description">aj</a>.
</p></dd><dt><span class="term">Custom class loader</span></dt><dd><p> A public interface is provided to allow a user written class loader
to instantiate a weaver and weave classes after loading and before
defining them in the JVM. This enables load-time weaving to be supported in
environments where no weaving agent is available. It also allows the
user to explicitly restrict by class loader which classes can be woven.
For more information, see <a class="xref" href="aj-ref.html#aj" title="Description">aj</a> and the
API documentation and source for
<code class="literal">WeavingURLClassLoader</code> and
<code class="literal">WeavingAdapter</code>.
</p></dd></dl></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-load-time-weaving-with-aopxml-files"></a>Configuring Load-time Weaving with aop.xml files</h3></div></div></div><p>The weaver is configured using one or more <code class="literal">META-INF/aop.xml</code>
files located on the class loader search path. Each file may declare a list of
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: </p><pre class="programlisting">
<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 to the weaver
use aspects matching the type pattern "com..*" for weaving. -->
<include within="com..*"/>
<!-- Of the set of aspects declared to the weaver
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.*"/>
<!-- Do not weave types within the "bar" pakage -->
<exclude within="bar.*"/>
<!-- Dump all types within the "com.foo.bar" package
to the "./_ajdump" folder on disk (for diagnostic purposes) -->
<dump within="com.foo.bar.*"/>
<!-- Dump all types within the "com.foo.bar" package and sub-packages,
both before are after they are woven,
which can be used for byte-code generated at runtime
<dump within="com.foo.bar..*" beforeandafter="true"/>
</weaver>
</aspectj>
</pre><p>
The DTD defining the format of this file is available here:
http://www.eclipse.org/aspectj/dtd/aspectj.dtd.
</p><p>
An aop.xml file contains two key sections: <code class="literal">aspects</code> defines one
or more aspects to the weaver and controls which aspects are to be
used in the weaving process; <code class="literal">weaver</code> defines weaver options and which
types should be woven.
</p><p>
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 <code class="literal">concrete-aspect</code> 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.
</p><p>
The <code class="literal">aspects</code> element may optionally contain one or more <code class="literal">include</code> and
<code class="literal">exclude</code> 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 <code class="literal">within</code> attribute accepts
a type pattern of the same form as a within pcd, except that &&
and || are replaced by 'AND' and 'OR'.
</p><p>
Note that <code class="literal">include</code> and <code class="literal">exclude</code> elements affect all aspects
declared to the weaver including those in other aop.xml files. To help avoid unexpected
behaviour a lint warning is issued
if an aspect is not declared as a result of of applying these filters.
Also note <code class="literal">aspect</code> and <code class="literal">concrete-aspect</code> elements
must be used to declare aspects to the weaver i.e. <code class="literal">include</code> and <code class="literal">exclude</code>
elements cannot be used find aspects on the class loader search path.
</p><p>
The <code class="literal">weaver</code> 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 visible to the weaver will be woven. In addition the <code class="literal">dump</code>
element can be used capture on disk byte-code of woven classes for diagnostic purposes both before,
in the case of those generated at runtime, and after the weaving process.
</p><p> When several configuration files are visible from a given weaving class loader
their contents are conceptually merged.
The files are merged in the order they are
found on the search path (with a regular <code class="literal">getResourceAsStream</code> lookup)
according to the following rules: </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The set of available aspects is the set of all
declared and defined aspects (<code class="literal">aspect</code> and
<code class="literal">concrete-aspect</code> elements of the <code class="literal">aspects</code>
section).</p></li><li class="listitem"><p>The set of aspects used for weaving is the subset of the available
aspects that are matched by at least one include statement and are not matched
by any exclude statements. If there are no include statements then all non-excluded
aspects are included.</p></li><li class="listitem"><p> The set of types to be woven are those types matched by at
least one weaver <code class="literal">include</code> element and not matched by any
weaver <code class="literal">exclude</code> element. If there are no weaver include
statements then all non-excluded types are included.</p></li><li class="listitem"><p> The weaver options are derived by taking the union of the
options specified in each of the weaver options attribute specifications. Where an
option takes a value e.g. <code class="literal">-warn:none</code> the most recently defined value
will be used.</p></li></ul></div><p>It is not an error for the same aspect to be defined to the weaver in
more than one visible <code class="literal">META-INF/aop.xml</code> file.
However, if the same concrete aspect
is defined in more than one 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.
</p><p> A <code class="literal">META-INF/aop.xml</code> can be generated by
using either the <code class="literal">-outxml</code> or <code class="literal">-outxmlfile</code> options of the AspectJ compiler.
It will simply contain a (possibly empty) set of aspect elements; one for
each abstract or concrete aspect defined.
When used in conjuction with the <code class="literal">-outjar</code> option
a JAR is produced that can be used
with the <span class="command"><strong>aj5</strong></span> command or a load-time weaving environment.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="concrete-aspect"></a>Using Concrete Aspects</h3></div></div></div><p>
It is possible to make an abstract aspect concrete by means of the <code class="literal">META-INF/aop.xml</code>
file. This is useful way to implement abstract pointcuts at deployment time, and also gives control
over precedence through the <code class="literal">precedence</code> attribute of the
<code class="literal">concrete-aspect</code> XML element.
Consider the following:
</p><pre class="programlisting">
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) {
....
}
}
</pre><p>
This aspect is equivalent to the following in code style:
</p><pre class="programlisting">
package mypack;
public abstract aspect AbstractAspect {
// abstract pointcut: no expression is defined
abstract pointcut scope();
before() : scope() && execution(* *..doSome(..)) {
....
}
}
</pre><p>
This aspect (in either style) can be made concrete using <code class="literal">META-INF/aop.xml</code>.
It defines the abstract pointcut <code class="literal">scope()</code>. When using this mechanism the
following rules apply:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The parent aspect must be abstract. It can be an @AspectJ or a
regular code style aspect.</p></li><li class="listitem"><p>Only a simple abstract pointcut can be implemented i.e. a pointcut that doesn't expose
state (through <code class="literal">args(), this(), target(), if()</code>). In @AspectJ syntax
as illustrated in this sample, this means the method that hosts the pointcut must be abstract,
have no arguments, and return void.</p></li><li class="listitem"><p>The concrete aspect must implement all inherited abstract pointcuts.</p></li><li class="listitem"><p>The concrete aspect may not implement methods so the abstract aspect it
extends may not contain any abstract methods.</p></li></ul></div><p>
</p><p>
<span class="emphasis"><em>A limitation of the implementation of this feature in AspectJ 1.5.0 is that aspects defined using
aop.xml are not exposed to the weaver. This means that they are not affected by advice and ITDs defined in
other aspects. Support for this capability will be considered in a future release.</em></span>
</p><p>
If more complex aspect inheritance is required use regular aspect
inheritance instead of XML.
The following XML definition shows a valid concrete sub-aspect for the abstract aspects above:
</p><pre class="programlisting">
<aspectj>
<aspects>
<concrete-aspect name="mypack.__My__AbstractAspect" extends="mypack.AbstractAspect">
<pointcut name="scope" expression="within(yourpackage..*)"/>
</concrete-aspect>
<aspects>
</aspectj>
</pre><p>
It is important to remember that the <code class="literal">name</code> attribute in the
<code class="literal">concrete-aspect</code> directive defines the fully qualified name that will be given to the
concrete aspect. It must a valid class name because the aspect will be generated on the fly by the weaver.
You must
also ensure that there are no name collisions. 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 <code class="literal">aspectof</code> methods to access the aspect instance(s) (depending on the perclause
of the aspect it extends) you have to use the helper API <code class="literal">org.aspectj.lang.Aspects.aspectOf(..)</code>
as in:
</p><pre class="programlisting">
// exception handling omitted
Class myConcreteAspectClass = Class.forName("mypack.__My__AbstractAspect");
// here we are using a singleton aspect
AbstractAspect concreteInstance = Aspects.aspectOf(myConcreteAspectClass);
</pre></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="concrete-aspect-precedence"></a>Using Concrete Aspects to define precedence</h3></div></div></div><p>
As described in the previous section, the <code class="literal">concrete-aspect</code> element in
<code class="literal">META-INF/aop.xml</code> gives the option to declare the precedence, just as
<code class="literal">@DeclarePrecedence</code> or <code class="literal">declare precedence</code> do in
aspect source code.
</p><p>
Sometimes it is necessary to declare precedence without extending any abstract aspect.
It is therefore possible to use the <code class="literal">concrete-aspect</code>
element without the <code class="literal">extends</code> attribute and without any
<code class="literal">pointcut</code> nested elements, just a <code class="literal">precedence</code>
attribute.
Consider the following:
</p><pre class="programlisting">
<aspectj>
<aspects>
<concrete-aspect name="mypack.__MyDeclarePrecedence"
precedence="*..*Security*, Logging+, *"/>
</aspects>
</aspectj>
</pre><p>
This deployment time definitions is only declaring a precedence rule. You have to remember
that the <code class="literal">name</code> 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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="weaver-options"></a>Weaver Options</h3></div></div></div><p> The table below lists the AspectJ options supported by LTW. All other options
will be ignored and a warning issued. </p><div class="informaltable"><table class="informaltable" border="1"><colgroup><col><col></colgroup><thead><tr><th>Option</th><th>Purpose</th></tr></thead><tbody><tr><td>
<code class="literal">-verbose</code>
</td><td>Issue informational messages about the weaving process. Messages issued while the weaver is being
bootstrapped are accumulated until all options are parsed. If the messages are required to be output
immediately you can use the option <code class="literal">-Daj.weaving.verbose=true</code> on the JVM startup command line.
</td></tr><tr><td>
<code class="literal">-debug</code>
</td><td>
Issue a messages for each class passed to the weaver
indicating whether it was woven, excluded or ignored.
Also issue messages for classes
defined during the weaving process such as around advice
closures and concrete aspects defined in
<code class="literal">META-INF/aop.xml</code>.
</td></tr><tr><td>
<code class="literal">-showWeaveInfo</code>
</td><td>
Issue informational messages whenever the weaver touches a class file.
This option may also be enabled using the System property
<code class="literal">-Dorg.aspectj.weaver.showWeaveInfo=true</code>.
</td></tr><tr><td>
<code class="literal">-Xlintfile:pathToAResource</code>
</td><td>Configure lint messages as specified in the given resource (visible from this aop.xml file' classloader)</td></tr><tr><td>
<code class="literal">-Xlint:default, -Xlint:ignore, ...</code>
</td><td>Configure lint messages, refer to documentation for meaningfull values</td></tr><tr><td>
<code class="literal">-nowarn, -warn:none</code>
</td><td>Suppress warning messages</td></tr><tr><td>
<code class="literal">-Xreweavable</code>
</td><td>Produce class files that can subsequently be rewoven</td></tr><tr><td>
<code class="literal">-XnoInline</code>
</td><td>Don't inline around advice.</td></tr><tr><td>
<code class="literal">-XmessageHandlerClass:...</code>
</td><td>Provide alternative output destination to stdout/stderr for all weaver messages.
The given value must be the full qualified class name of a class that implements the
<code class="literal">org.aspectj.bridge.IMessageHandler</code> interface
and is visible to the classloader with which the weaver being configured is associated.
Exercise caution when packaging a custom message handler with an application that is to
be woven. The handler (as well as classes on which it depends) cannot itself be woven
by the aspects that are declared to the same weaver.
</td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ltw-rules.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ltw.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ltw-specialcases.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Load-time Weaving Requirements </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Special cases</td></tr></table></div></body></html>
|