You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

ltw.xml 34KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603
  1. <chapter id="ltw" xreflabel="Load-Time Weaving">
  2. <title>Load-Time Weaving</title>
  3. <sect1 id="ltw-introduction">
  4. <title>Introduction</title>
  5. <para> The AspectJ weaver takes class files as input and produces class files as output.
  6. The weaving process itself can take place at one of three different times: compile-time,
  7. post-compile time, and load-time. The class files produced by the weaving process (and
  8. hence the run-time behaviour of an application) are the same regardless of the approach
  9. chosen. </para>
  10. <itemizedlist>
  11. <listitem> <para>Compile-time weaving is the simplest approach. When you have the source code
  12. for an application, ajc will compile from source and produce woven class files as
  13. output. The invocation of the weaver is integral to the ajc compilation process. The
  14. aspects themselves may be in source or binary form.
  15. If the aspects are required for the affected classes to compile, then
  16. you must weave at compile-time. Aspects are required, e.g., when they
  17. add members to a class and other classes being compiled reference the
  18. added members.
  19. </para></listitem>
  20. <listitem> <para>Post-compile weaving (also sometimes called binary weaving) is used to weave
  21. existing class files and JAR files. As with compile-time weaving,
  22. the aspects used for weaving may be in source or binary form,
  23. and may themselves be woven by aspects.</para></listitem>
  24. <listitem> <para>Load-time weaving (LTW) is simply binary weaving defered until the point that
  25. a class loader loads a class file and defines the class to the JVM. To support this,
  26. one or more "weaving class loaders", either provided explicitly by the run-time
  27. environment or enabled through a "weaving agent" are required. </para></listitem>
  28. </itemizedlist>
  29. <para> You may also hear the term "run-time weaving". We define this as the weaving of
  30. classes that have already been defined to the JVM (without reloading those
  31. classes). AspectJ 5 does not provide explicit support for run-time weaving although
  32. simple coding patterns can support dynamically enabling and disabling advice in aspects. </para>
  33. <sect2 id="weaving-class-files-more-than-once" xreflabel="weaving-class-files-more-than-once">
  34. <title>Weaving class files more than once</title>
  35. <para> As of AspectJ 5 aspects (code style or annotation style) and woven classes are
  36. reweavable by default. If you are developing AspectJ applications that are to be used
  37. in a load-time weaving environment with an older version of the compiler you
  38. need to specify the <literal>-Xreweavable</literal> compiler option when building
  39. them. This causes AspectJ to save additional state in the class files that is used
  40. to support subsequent reweaving. </para>
  41. </sect2>
  42. </sect1>
  43. <sect1 id="ltw-rules">
  44. <title>Load-time Weaving Requirements</title>
  45. <para> All load-time weaving is done in the context of a class loader, and hence the set of
  46. aspects used for weaving and the types that can be woven are affected by the class
  47. loader delegation model. This ensures that LTW complies with the Java 2 security model.
  48. The following rules govern the interaction of load-time weaving with class loading: </para>
  49. <orderedlist>
  50. <listitem> <para>All aspects to be used for weaving must be defined to the weaver before any
  51. types to be woven are loaded. This avoids types being "missed" by aspects added
  52. later, with the result that invariants across types fail.</para></listitem>
  53. <listitem> <para>All aspects visible to the weaver are usable.
  54. A visible aspect is one defined by the
  55. weaving class loader or one of its parent class loaders.
  56. All concrete visible aspects are woven and all abstract visible aspects
  57. may be extended.
  58. </para></listitem>
  59. <listitem><para>A class loader may only weave classes that it defines. It may not weave
  60. classes loaded by a delegate or parent class loader.</para></listitem>
  61. </orderedlist>
  62. </sect1>
  63. <sect1 id="ltw-configuration">
  64. <title>Configuration</title>
  65. <para>New in AspectJ 5 are a number of mechanisms to make load-time weaving
  66. easy to use. The load-time weaving mechanism is chosen through JVM startup options.
  67. Configuration files determine the set of aspects to be used for weaving and which
  68. types will be woven. Additional diagnostic options allow the user to debug the configuration and
  69. weaving process. </para>
  70. <sect2 id="enabling-load-time-weaving" xreflabel="enabling-load-time-weaving">
  71. <title>Enabling Load-time Weaving</title>
  72. <para> AspectJ 5 supports several ways of enabling load-time weaving for
  73. an application: agents, a command-line launch script, and a set of interfaces for
  74. integration of AspectJ load-time weaving in custom environments. </para>
  75. <variablelist>
  76. <varlistentry>
  77. <term>Agents</term>
  78. <listitem>
  79. <para>AspectJ 5 ships with a number of load-time weaving agents that
  80. enable load-time weaving. These agents and their configuration
  81. are execution environment dependent. Configuration for the supported environments is discussed
  82. later in this chapter.</para>
  83. <para>
  84. Using Java 5 JVMTI you can specify the <literal>-javaagent:pathto/aspectjweaver.jar</literal> option
  85. to the JVM.</para><para>
  86. Using BEA JRockit and Java 1.3/1.4, the very same behavior can be obtained using BEA JRockit JMAPI features with
  87. the <literal>-Xmanagement:class=org.aspectj.weaver.loadtime.JRockitAgent</literal>
  88. </para>
  89. </listitem>
  90. </varlistentry>
  91. <varlistentry>
  92. <term>Command-line wrapper scripts <literal>aj</literal></term>
  93. <listitem>
  94. <para>The <command>aj</command> command runs Java programs in Java 1.4 or
  95. later by setting up <literal>WeavingURLClassLoader</literal> as the
  96. system class loader.
  97. For more information, see <xref linkend="aj"/>.
  98. </para>
  99. <para>The <command>aj5</command> command runs Java programs in Java 5
  100. by using the <literal>-javaagent:pathto/aspectjweaver.jar</literal> option
  101. described above.
  102. For more information, see <xref linkend="aj"/>.
  103. </para>
  104. </listitem>
  105. </varlistentry>
  106. <varlistentry>
  107. <term>Custom class loader</term>
  108. <listitem>
  109. <para> A public interface is provided to allow a user written class loader
  110. to instantiate a weaver and weave classes after loading and before
  111. defining them in the JVM. This enables load-time weaving to be supported in
  112. environments where no weaving agent is available. It also allows the
  113. user to explicitly restrict by class loader which classes can be woven.
  114. For more information, see <xref linkend="aj"/> and the
  115. API documentation and source for
  116. <literal>WeavingURLClassLoader</literal> and
  117. <literal>WeavingAdapter</literal>.
  118. </para>
  119. </listitem>
  120. </varlistentry>
  121. </variablelist>
  122. </sect2>
  123. <sect2 id="configuring-load-time-weaving-with-aopxml-files" xreflabel="configuring-load-time-weaving-with-aopxml-files">
  124. <title>Configuring Load-time Weaving with aop.xml files</title>
  125. <para>The weaver is configured using one or more <literal>META-INF/aop.xml</literal>
  126. files located on the class loader search path. Each file may declare a list of
  127. aspects to be used for weaving, type patterns describing which types
  128. should woven, and a set of options to be passed to the weaver. In addition AspectJ 5
  129. supports the definition of concrete aspects in XML. Aspects defined in this way
  130. must extend an abstract aspect visible to the weaver. The abstract aspect
  131. may define abstract pointcuts (but not abstract
  132. methods). The following example shows a simple aop.xml file: </para>
  133. <programlisting><![CDATA[
  134. <aspectj>
  135. <aspects>
  136. <!-- declare two existing aspects to the weaver -->
  137. <aspect name="com.MyAspect"/>
  138. <aspect name="com.MyAspect.Inner"/>
  139. <!-- define a concrete aspect inline -->
  140. <concrete-aspect name="com.xyz.tracing.MyTracing"
  141. extends="tracing.AbstractTracing"
  142. precedence="com.xyz.first, *">
  143. <pointcut name="tracingScope" expression="within(org.maw.*)"/>
  144. </concrete-aspect>
  145. <!-- Of the set of aspects declared to the weaver
  146. use aspects matching the type pattern "com..*" for weaving. -->
  147. <include within="com..*"/>
  148. <!-- Of the set of aspects declared to the weaver
  149. do not use any aspects with the @CoolAspect annotation for weaving -->
  150. <exclude within="@CoolAspect *"/>
  151. </aspects>
  152. <weaver options="-verbose">
  153. <!-- Weave types that are within the javax.* or org.aspectj.*
  154. packages. Also weave all types in the foo package that do
  155. not have the @NoWeave annotation. -->
  156. <include within="javax.*"/>
  157. <include within="org.aspectj.*"/>
  158. <include within="(!@NoWeave foo.*) AND foo.*"/>
  159. <!-- Do not weave types within the "bar" pakage -->
  160. <exclude within="bar.*"/>
  161. <!-- Dump all types within the "com.foo.bar" package
  162. to the "./_ajdump" folder on disk (for diagnostic purposes) -->
  163. <dump within="com.foo.bar.*"/>
  164. <!-- Dump all types within the "com.foo.bar" package and sub-packages,
  165. both before are after they are woven,
  166. which can be used for byte-code generated at runtime
  167. <dump within="com.foo.bar..*" beforeandafter="true"/>
  168. </weaver>
  169. </aspectj>
  170. ]]></programlisting>
  171. <para>
  172. An aop.xml file contains two key sections: <literal>aspects</literal> defines one
  173. or more aspects to the weaver and controls which aspects are to be
  174. used in the weaving process; <literal>weaver</literal> defines weaver options and which
  175. types should be woven.
  176. </para>
  177. <para>
  178. The simplest way to define an aspect to the weaver is to
  179. specify the fully-qualified name of the aspect type in an aspect element.
  180. You can also
  181. declare (and define to the weaver) aspects inline in the aop.xml file.
  182. This is done using the <literal>concrete-aspect</literal> element. A concrete-aspect
  183. declaration must provide a pointcut definition for every abstract
  184. pointcut in the abstract aspect it extends. This mechanism is a
  185. useful way of externalizing configuration for infrastructure and
  186. auxiliary aspects where the pointcut definitions themselves can be
  187. considered part of the configuration of the service.
  188. Refer to the next section for more details.
  189. </para>
  190. <para>
  191. The <literal>aspects</literal> element may optionally contain one or more <literal>include</literal> and
  192. <literal>exclude</literal> elements (by default, all defined aspects are used for weaving).
  193. Specifying include or exclude elements restricts the set of defined
  194. aspects to be used for weaving to those that are matched by an include
  195. pattern, but not by an exclude pattern. The <literal>within</literal> attribute accepts
  196. a type pattern of the same form as a within pcd, except that &amp;&amp;
  197. and || are replaced by 'AND' and 'OR'.
  198. </para>
  199. <para>
  200. Note that <literal>include</literal> and <literal>exclude</literal> elements affect all aspects
  201. declared to the weaver including those in other aop.xml files. To help avoid unexpected
  202. behaviour a lint warning is issued
  203. if an aspect is not declared as a result of of applying these filters.
  204. Also note <literal>aspect</literal> and <literal>concrete-aspect</literal> elements
  205. must be used to declare aspects to the weaver i.e. <literal>include</literal> and <literal>exclude</literal>
  206. elements cannot be used find aspects on the class loader search path.
  207. </para>
  208. <para>
  209. The <literal>weaver</literal> element is used to pass options to the weaver and to specify
  210. the set of types that should be woven. If no include elements are specified
  211. then all types visible to the weaver will be woven. In addition the <literal>dump</literal>
  212. element can be used capture on disk byte-code of woven classes for diagnostic purposes both before,
  213. in the case of those generated at runtime, and after the weaving process.
  214. </para>
  215. <para> When several configuration files are visible from a given weaving class loader
  216. their contents are conceptually merged.
  217. The files are merged in the order they are
  218. found on the search path (with a regular <literal>getResourceAsStream</literal> lookup)
  219. according to the following rules: </para>
  220. <itemizedlist>
  221. <!-- FIXME AV - looks like we can refine conf in a child CL - not good -->
  222. <listitem> <para>The set of available aspects is the set of all
  223. declared and defined aspects (<literal>aspect</literal> and
  224. <literal>concrete-aspect</literal> elements of the <literal>aspects</literal>
  225. section).</para></listitem>
  226. <listitem> <para>The set of aspects used for weaving is the subset of the available
  227. aspects that are matched by at least one include statement and are not matched
  228. by any exclude statements. If there are no include statements then all non-excluded
  229. aspects are included.</para></listitem>
  230. <listitem> <para> The set of types to be woven are those types matched by at
  231. least one weaver <literal>include</literal> element and not matched by any
  232. weaver <literal>exclude</literal> element. If there are no weaver include
  233. statements then all non-excluded types are included.</para></listitem>
  234. <listitem> <para> The weaver options are derived by taking the union of the
  235. options specified in each of the weaver options attribute specifications. Where an
  236. option takes a value e.g. <literal>-warn:none</literal> the most recently defined value
  237. will be used.</para></listitem>
  238. </itemizedlist>
  239. <para>It is not an error for the same aspect to be defined to the weaver in
  240. more than one visible <literal>META-INF/aop.xml</literal> file.
  241. However, if the same concrete aspect
  242. is defined in more than one aop.xml file then an error will be issued.
  243. A concrete aspect
  244. defined in this way will be used to weave types loaded by the
  245. class loader that loaded the aop.xml file in which it was defined.
  246. </para>
  247. <para> A <literal>META-INF/aop.xml</literal> can be generated by
  248. using either the <literal>-outxml</literal> or <literal>-outxmlfile</literal> options of the AspectJ compiler.
  249. It will simply contain a (possibly empty) set of aspect elements; one for
  250. each abstract or concrete aspect defined.
  251. When used in conjuction with the <literal>-outjar</literal> option
  252. a JAR is produced that can be used
  253. with the <command>aj5</command> command or a load-time weaving environment.</para>
  254. </sect2>
  255. <sect2 id="concrete-aspect" xreflabel="concrete-aspect">
  256. <title>Using Concrete Aspects</title>
  257. <para>
  258. It is possible to make an abstract aspect concrete by means of the <literal>META-INF/aop.xml</literal>
  259. file. This is useful way to implement abstract pointcuts at deployment time, and also gives control
  260. over precedence through the <literal>precedence</literal> attribute of the
  261. <literal>concrete-aspect</literal> XML element.
  262. Consider the following:
  263. </para>
  264. <programlisting><![CDATA[
  265. package mypack;
  266. @Aspect
  267. public abstract class AbstractAspect {
  268. // abstract pointcut: no expression is defined
  269. @Pointcut
  270. abstract void scope();
  271. @Before("scope() && execution(* *..doSome(..))")
  272. public void before(JoinPoint jp) {
  273. ....
  274. }
  275. }
  276. ]]></programlisting>
  277. <para>
  278. This aspect is equivalent to the following in code style:
  279. </para>
  280. <programlisting><![CDATA[
  281. package mypack;
  282. public abstract aspect AbstractAspect {
  283. // abstract pointcut: no expression is defined
  284. abstract pointcut scope();
  285. before() : scope() && execution(* *..doSome(..)) {
  286. ....
  287. }
  288. }
  289. ]]></programlisting>
  290. <para>
  291. This aspect (in either style) can be made concrete using <literal>META-INF/aop.xml</literal>.
  292. It defines the abstract pointcut <literal>scope()</literal>. When using this mechanism the
  293. following rules apply:
  294. <itemizedlist>
  295. <listitem><para>The parent aspect must be abstract. It can be an @AspectJ or a
  296. regular code style aspect.</para></listitem>
  297. <listitem><para>Only a simple abstract pointcut can be implemented i.e. a pointcut that doesn't expose
  298. state (through <literal>args(), this(), target(), if()</literal>). In @AspectJ syntax
  299. as illustrated in this sample, this means the method that hosts the pointcut must be abstract,
  300. have no arguments, and return void.</para></listitem>
  301. <listitem><para>The concrete aspect must implement all inherited abstract pointcuts.</para></listitem>
  302. <listitem><para>The concrete aspect may not implement methods so the abstract aspect it
  303. extends may not contain any abstract methods.</para></listitem>
  304. </itemizedlist>
  305. </para>
  306. <para>
  307. <emphasis>A limitation of the implementation of this feature in AspectJ 1.5.0 is that aspects defined using
  308. aop.xml are not exposed to the weaver. This means that they are not affected by advice and ITDs defined in
  309. other aspects. Support for this capability will be considered in a future release.</emphasis>
  310. </para>
  311. <para>
  312. If more complex aspect inheritance is required use regular aspect
  313. inheritance instead of XML.
  314. The following XML definition shows a valid concrete sub-aspect for the abstract aspects above:
  315. </para>
  316. <programlisting><![CDATA[
  317. <aspectj>
  318. <aspects>
  319. <concrete-aspect name="mypack.__My__AbstractAspect" extends="mypack.AbstractAspect">
  320. <pointcut name="scope" expression="within(yourpackage..*)"/>
  321. </concrete-aspect>
  322. <aspects>
  323. </aspectj>
  324. ]]></programlisting>
  325. <para>
  326. It is important to remember that the <literal>name</literal> attribute in the
  327. <literal>concrete-aspect</literal> directive defines the fully qualified name that will be given to the
  328. concrete aspect. It must a valid class name because the aspect will be generated on the fly by the weaver.
  329. You must
  330. also ensure that there are no name collisions. Note that the concrete aspect will be
  331. defined at the classloader level for which the aop.xml is visible. This implies that if you need
  332. to use the <literal>aspectof</literal> methods to access the aspect instance(s) (depending on the perclause
  333. of the aspect it extends) you have to use the helper API <literal>org.aspectj.lang.Aspects.aspectOf(..)</literal>
  334. as in:
  335. </para>
  336. <programlisting><![CDATA[
  337. // exception handling omitted
  338. Class myConcreteAspectClass = Class.forName("mypack.__My__AbstractAspect");
  339. // here we are using a singleton aspect
  340. AbstractAspect concreteInstance = Aspects.aspectOf(myConcreteAspectClass);
  341. ]]></programlisting>
  342. </sect2>
  343. <sect2 id="concrete-aspect-precedence" xreflabel="concrete-aspect-precedence">
  344. <title>Using Concrete Aspects to define precedence</title>
  345. <para>
  346. As described in the previous section, the <literal>concrete-aspect</literal> element in
  347. <literal>META-INF/aop.xml</literal> gives the option to declare the precedence, just as
  348. <literal>@DeclarePrecedence</literal> or <literal>declare precedence</literal> do in
  349. aspect source code.
  350. </para>
  351. <para>
  352. Sometimes it is necessary to declare precedence without extending any abstract aspect.
  353. It is therefore possible to use the <literal>concrete-aspect</literal>
  354. element without the <literal>extends</literal> attribute and without any
  355. <literal>pointcut</literal> nested elements, just a <literal>precedence</literal>
  356. attribute.
  357. Consider the following:
  358. </para>
  359. <programlisting><![CDATA[
  360. <aspectj>
  361. <aspects>
  362. <concrete-aspect name="mypack.__MyDeclarePrecedence"
  363. precedence="*..*Security*, Logging+, *"/>
  364. </aspects>
  365. </aspectj>
  366. ]]></programlisting>
  367. <para>
  368. This deployment time definitions is only declaring a precedence rule. You have to remember
  369. that the <literal>name</literal> attribute must be a valid fully qualified class name
  370. that will be then reserved for this concrete-aspect and must not conflict with other classes
  371. you deploy.
  372. </para>
  373. </sect2>
  374. <!-- TODO someone implement that -->
  375. <!--
  376. <sect2 id="configuring-load-time-weaving-with-properties-files" xreflabel="configuring-load-time-weaving-with-properties-files">
  377. <title>Configuring Load-time Weaving with Properties Files</title>
  378. <para> For memory constrained environments or those without support for XML a simple
  379. Java Properties file can be used to configure LTW. Just like XML files,
  380. <literal>META-INF/aop.properties</literal> files are loaded from the class loader
  381. search path. Everything that can be configured through XML can be configured using a
  382. Properties file, with the exception of declarative concrete aspects. For example: </para>
  383. <programlisting><![CDATA[
  384. aspects.names=com.MyAspect,com.MyAspect.Inner
  385. aspects.include=com..*
  386. aspects.exclude=@CoolAspect
  387. weaver.options=-verbose
  388. weaver.include=javax.* OR org.aspectj.*
  389. ]]></programlisting>
  390. </sect2>
  391. -->
  392. <sect2 id="weaver-options" xreflabel="weaver-options">
  393. <title>Weaver Options</title>
  394. <para> The table below lists the AspectJ options supported by LTW. All other options
  395. will be ignored and a warning issued. </para>
  396. <informaltable>
  397. <tgroup cols="2">
  398. <thead>
  399. <row>
  400. <entry>Option</entry>
  401. <entry>Purpose</entry>
  402. </row>
  403. </thead>
  404. <tbody>
  405. <row>
  406. <entry>
  407. <literal>-verbose</literal>
  408. </entry>
  409. <entry>Issue informational messages about the weaving process. Messages issued while the weaver is being
  410. bootstrapped are accumulated until all options are parsed. If the messages are required to be output
  411. immediately you can use the option <literal>-Daj.weaving.verbose=true</literal> on the JVM startup command line.
  412. </entry>
  413. </row>
  414. <row>
  415. <entry>
  416. <literal>-debug</literal>
  417. </entry>
  418. <entry>
  419. Issue a messages for each class passed to the weaver
  420. indicating whether it was woven, excluded or ignored.
  421. Also issue messages for classes
  422. defined during the weaving process such as around advice
  423. closures and concrete aspects defined in
  424. <literal>META-INF/aop.xml</literal>.
  425. </entry>
  426. </row>
  427. <row>
  428. <entry>
  429. <literal>-showWeaveInfo</literal>
  430. </entry>
  431. <entry>
  432. Issue informational messages whenever the weaver touches a class file.
  433. This option may also be enabled using the System property
  434. <literal>-Dorg.aspectj.weaver.showWeaveInfo=true</literal>.
  435. </entry>
  436. </row>
  437. <!-- TODO option parsed but not used -->
  438. <!--
  439. <row>
  440. <entry>
  441. <literal>-1.5</literal>
  442. </entry>
  443. <entry>Run the weaver in 1.5 mode (supports autoboxing in
  444. join point matching)</entry>
  445. </row>
  446. -->
  447. <row>
  448. <entry>
  449. <literal>-Xlintfile:pathToAResource</literal>
  450. </entry>
  451. <entry>Configure lint messages as specified in the given resource (visible from this aop.xml file' classloader)</entry>
  452. </row>
  453. <row>
  454. <entry>
  455. <literal>-Xlint:default, -Xlint:ignore, ...</literal>
  456. </entry>
  457. <entry>Configure lint messages, refer to documentation for meaningfull values</entry>
  458. </row>
  459. <row>
  460. <entry>
  461. <literal>-nowarn, -warn:none</literal>
  462. </entry>
  463. <entry>Suppress warning messages</entry>
  464. </row>
  465. <!-- TODO option parsed but not used -->
  466. <!--
  467. <row>
  468. <entry>
  469. <literal>-proceedOnError</literal>
  470. </entry>
  471. <entry>Continue weaving even if errors occur (for example,
  472. "... already woven" errors)</entry>
  473. </row>
  474. -->
  475. <row>
  476. <entry>
  477. <literal>-Xreweavable</literal>
  478. </entry>
  479. <entry>Produce class files that can subsequently be rewoven</entry>
  480. </row>
  481. <row>
  482. <entry>
  483. <literal>-XnoInline</literal>
  484. </entry>
  485. <entry>Don't inline around advice.</entry>
  486. </row>
  487. <row>
  488. <entry>
  489. <literal>-XmessageHandlerClass:...</literal>
  490. </entry>
  491. <entry>Provide alternative output destination to stdout/stderr for all weaver messages.
  492. The given value must be the full qualified class name of a class that implements the
  493. <literal>org.aspectj.bridge.IMessageHandler</literal> interface
  494. and is visible to the classloader with which the weaver being configured is associated.
  495. Exercise caution when packaging a custom message handler with an application that is to
  496. be woven. The handler (as well as classes on which it depends) cannot itself be woven
  497. by the aspects that are declared to the same weaver.
  498. </entry>
  499. </row>
  500. </tbody>
  501. </tgroup>
  502. </informaltable>
  503. </sect2>
  504. </sect1>
  505. <sect1 id="ltw-specialcases">
  506. <title>Special cases</title>
  507. <para>
  508. The following classes are not exposed to the LTW infrastructure regardless of
  509. the <literal>aop.xml</literal> file(s) used:
  510. <itemizedlist>
  511. <listitem> <para>All <literal>org.aspectj.*</literal> classes (and subpackages) - as those are needed by the infrastructure itself</para></listitem>
  512. <listitem> <para>All <literal>java.*</literal> and <literal>javax.*</literal> classes (and subpackages)</para></listitem>
  513. <listitem> <para>All <literal>sun.reflect.*</literal> classes - as those are JDK specific classes used when reflective calls occurs</para></listitem>
  514. </itemizedlist>
  515. </para>
  516. <para>
  517. Despite these restrictions, it is perfectly possible to match call join points for calls to these types providing the calling
  518. class is exposed to the weaver. Subtypes of these excluded types that are exposed to the weaver may of course be woven.
  519. </para>
  520. <para>
  521. Note that dynamic proxy representations are exposed to the LTW infrastructure and are not considered
  522. a special case.
  523. </para>
  524. <para>
  525. Some lint options behave differently when used under load-time weaving. The <literal>adviceDidNotMatch</literal>
  526. won't be handled as a warn (as during compile time) but as an info message.
  527. </para>
  528. </sect1>
  529. <sect1 id="ltw-packaging">
  530. <title>Runtime Requirements for Load-time Weaving</title>
  531. <para> To use LTW the <literal>aspectjweaver.jar</literal> library must be added to the
  532. classpath. This contains the AspectJ 5 runtime, weaver, weaving class loader and
  533. weaving agents. It also contains the DTD for parsing XML weaving configuration files. </para>
  534. </sect1>
  535. <sect1 id="ltw-agents">
  536. <title>Supported Agents</title>
  537. <sect2 id="jvmti" xreflabel="jvmti">
  538. <title>JVMTI</title>
  539. <para> When using Java 5 the JVMTI agent can be used by starting the JVM with the
  540. following option (adapt according to the path to aspectjweaver.jar): </para>
  541. <programlisting><![CDATA[
  542. -javaagent:pathto/aspectjweaver.jar
  543. ]]></programlisting>
  544. </sect2>
  545. <sect2 id="jrockit" xreflabel="jrockit">
  546. <title>JRockit with Java 1.3/1.4 (use JVMTI on Java 5)</title>
  547. <para> The JRockit agent is configured with the following JVM option: </para>
  548. <programlisting><![CDATA[
  549. -Xmanagement:class=org.aspectj.weaver.loadtime.JRockitAgent
  550. ]]></programlisting>
  551. </sect2>
  552. </sect1>
  553. </chapter>