[jboss-cvs] JBossCache/docs/PojoCache/en/modules ...
Ben Wang
bwang at jboss.com
Wed Sep 27 02:49:42 EDT 2006
User: bwang
Date: 06/09/27 02:49:42
Modified: docs/PojoCache/en/modules appendix.xml configuration.xml
instrumentation.xml
Log:
Updated.
Revision Changes Path
1.3 +174 -6 JBossCache/docs/PojoCache/en/modules/appendix.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: appendix.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/appendix.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -b -r1.2 -r1.3
--- appendix.xml 28 Apr 2006 08:37:07 -0000 1.2
+++ appendix.xml 27 Sep 2006 06:49:42 -0000 1.3
@@ -12,10 +12,12 @@
(note that
neither class implements
<literal>Serializable</literal>
- ).
+ ) along with the annotation.
</para>
- <programlisting>public class Person {
+ <programlisting>
+ at org.jboss.cache.pojo.annotation.InstanceOfPojoCacheable
+public class Person {
String name=null;
int age=0;
Map hobbies=null;
@@ -49,7 +51,9 @@
public void setYear(String year) { this.year=year; }
}</programlisting>
- <programlisting>public class Address {
+ <programlisting>
+ at org.jboss.cache.pojo.annotation.PojoCacheable
+public class Address {
String street=null;
String city=null;
int zip=0;
@@ -61,11 +65,10 @@
</sect1>
<sect1 id="xml" revision="1">
- <title>Sample configuration xml</title>
+ <title>Sample Cache configuration xml</title>
<para>
- Below is a sample xml configuration for PojoCache. Today, it uses the same configuration option as that
- of TreeCache super-class except the MBean service class (if you are deploying it under JBoss).
+ Below is a sample xml configuration for Cache that you can use for PojoCache creation.
</para>
<programlisting>
<?xml version="1.0" encoding="UTF-8" ?>
@@ -156,5 +159,170 @@
</sect1>
+
+ <sect1 id="xml-pojo" revision="1">
+ <title>PojoCache configuration xml</title>
+ <para>Attached is a full listing for <literal>pojocache-aop.xml</literal>.</para>
+<programlisting>
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!--
+ This is the PojoCache configuration file that specifies:
+ 1. Interceptor stack for API
+ 2. Annotation binding for POJO (via "prepare" element)
+
+ Basically, this is a variant of jboss-aop.xml. Note that
+ except for the customization of interceptor stack, you should
+ not need to modify this file.
+
+ To run PojoCache, you will need to define a system property:
+ jboss.aop.path that contains the path to this file such that JBoss Aop
+ can locate it.
+ -->
+ <aop>
+
+ <!--
+ This defines the PojoCache 2.0 interceptor stack. Unless necessary, don't modify the stack here!
+ -->
+
+ <!-- Check id range validity -->
+ <interceptor name="CheckId" class="org.jboss.cache.pojo.interceptors.CheckIdInterceptor"
+ scope="PER_INSTANCE"/>
+
+ <!-- Track Tx undo operation -->
+ <interceptor name="Undo" class="org.jboss.cache.pojo.interceptors.PojoTxUndoInterceptor"
+ scope="PER_INSTANCE"/>
+
+ <!-- Begining of interceptor chain -->
+ <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor"
+ scope="PER_INSTANCE"/>
+
+ <!-- Check if we need a local tx for batch processing -->
+ <interceptor name="Tx" class="org.jboss.cache.pojo.interceptors.PojoTxInterceptor"
+ scope="PER_INSTANCE"/>
+
+ <!--
+ Mockup failed tx for testing. You will need to set PojoFailedTxMockupInterceptor.setRollback(true)
+ to activate it.
+ -->
+ <interceptor name="MockupTx" class="org.jboss.cache.pojo.interceptors.PojoFailedTxMockupInterceptor"
+ scope="PER_INSTANCE"/>
+
+ <!-- Perform parent level node locking -->
+ <interceptor name="TxLock" class="org.jboss.cache.pojo.interceptors.PojoTxLockInterceptor"
+ scope="PER_INSTANCE"/>
+
+ <!-- Interceptor to perform Pojo level rollback -->
+ <interceptor name="TxUndo" class="org.jboss.cache.pojo.interceptors.PojoTxUndoSynchronizationInterceptor"
+ scope="PER_INSTANCE"/>
+
+ <!-- Interceptor to used to check recursive field interception. -->
+ <interceptor name="Reentrant" class="org.jboss.cache.pojo.interceptors.MethodReentrancyStopperInterceptor"
+ scope="PER_INSTANCE"/>
+
+ <!-- Whether to allow non-serializable pojo. Default is false. -->
+ <interceptor name="MarshallNonSerializable"
+ class="org.jboss.cache.pojo.interceptors.CheckNonSerializableInterceptor"
+ scope="PER_INSTANCE">
+ <attribute name="marshallNonSerializable">false</attribute>
+ </interceptor>
+
+ <!-- This defines the stack macro -->
+ <stack name="Attach">
+ <interceptor-ref name="Start"/>
+ <interceptor-ref name="CheckId"/>
+ <interceptor-ref name="MarshallNonSerializable"/>
+ <interceptor-ref name="Tx"/>
+ <!-- NOTE: You can comment this out during production although leaving it here is OK. -->
+ <interceptor-ref name="MockupTx"/>
+ <interceptor-ref name="TxLock"/>
+ <interceptor-ref name="TxUndo"/>
+ </stack>
+
+ <stack name="Detach">
+ <interceptor-ref name="Start"/>
+ <interceptor-ref name="CheckId"/>
+ <interceptor-ref name="Tx"/>
+ <!-- NOTE: You can comment this out during production although leaving it here is OK. -->
+ <interceptor-ref name="MockupTx"/>
+ <interceptor-ref name="TxLock"/>
+ <interceptor-ref name="TxUndo"/>
+ </stack>
+
+ <stack name="Find">
+ <interceptor-ref name="Start"/>
+ <interceptor-ref name="CheckId"/>
+ </stack>
+
+ <!--
+ The following section should be READ-ONLY!! It defines the annotation binding to the stack.
+ -->
+
+ <!-- This binds the jointpoint to specific in-memory operations. Currently in PojoUtil. -->
+ <bind pointcut="execution(*
+ @org.jboss.cache.pojo.annotation.Reentrant->toString())">
+ <interceptor-ref name="Reentrant"/>
+ </bind>
+
+ <bind pointcut="execution(*
+ org.jboss.cache.pojo.PojoUtil->@org.jboss.cache.pojo.annotation.TxUndo(..))">
+ <interceptor-ref name="Undo"/>
+ </bind>
+
+ <bind pointcut="execution(* org.jboss.cache.pojo.impl.PojoCacheImpl->@org.jboss.cache.pojo.annotation.Attach(..))">
+ <stack-ref name="Attach"/>
+ </bind>
+
+ <bind pointcut="execution(* org.jboss.cache.pojo.impl.PojoCacheImpl->@org.jboss.cache.pojo.annotation.Detach(..))">
+ <stack-ref name="Detach"/>
+ </bind>
+
+ <bind pointcut="execution(* org.jboss.cache.pojo.impl.PojoCacheImpl->@org.jboss.cache.pojo.annotation.Find(..))">
+ <stack-ref name="Find"/>
+ </bind>
+
+
+ <!--
+ Following is declaration for JDK50 annotation. You use the specific annotation on your
+ POJO such that it can be instrumented. Idea is user will then need only to annotate like:
+ @org.jboss.cache.pojo.annotation.PojoCacheable
+ in his POJO. There will be no need of jboss-aop.xml from user's side.
+ -->
+
+ <!-- If a POJO has PojoCachable annotation, it will be asepctized. -->
+ <prepare expr="field(* @org.jboss.cache.pojo.annotation.PojoCacheable->*)" />
+
+ <!--
+ Supports inheritance and polymorphism. It can either be a concrete class
+ or an interface. All sub-classes or interface implementors will be instrumeneted.
+ -->
+ <prepare expr="field(* $instanceof{@org.jboss.cache.pojo.annotation.InstanceOfPojoCacheable}->*)" />
+
+ <!-- Observer and Observable to monitor field modification -->
+ <bind pointcut="
+ set(* $instanceof{@org.jboss.cache.pojo.annotation.InstanceOfPojoCacheable}->*) OR
+ set(* @org.jboss.cache.pojo.annotation.PojoCacheable->*)
+ ">
+ <interceptor class="org.jboss.cache.pojo.observable.SubjectInterceptor"/>
+ </bind>
+
+ <introduction class="$instanceof{@org.jboss.cache.pojo.annotation.InstanceOfPojoCacheable}">
+ <mixin>
+ <interfaces>org.jboss.cache.pojo.observable.Subject</interfaces>
+ <class>org.jboss.cache.pojo.observable.SubjectImpl</class>
+ <construction>new org.jboss.cache.pojo.observable.SubjectImpl(this)</construction>
+ </mixin>
+ </introduction>
+
+ <introduction class="@org.jboss.cache.pojo.annotation.PojoCacheable">
+ <mixin>
+ <interfaces>org.jboss.cache.pojo.observable.Subject</interfaces>
+ <class>org.jboss.cache.pojo.observable.SubjectImpl</class>
+ <construction>new org.jboss.cache.pojo.observable.SubjectImpl(this)</construction>
+ </mixin>
+ </introduction>
+ </aop>
+
+</programlisting>
+ </sect1>
</chapter>
1.4 +73 -9 JBossCache/docs/PojoCache/en/modules/configuration.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: configuration.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/configuration.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -b -r1.3 -r1.4
--- configuration.xml 21 Aug 2006 00:36:33 -0000 1.3
+++ configuration.xml 27 Sep 2006 06:49:42 -0000 1.4
@@ -6,19 +6,83 @@
<para>Since PojoCache uses Cache as a delegate for the underlying node replication,
transaction,
locking, and passivation behavior, user of PojoCache will need to configure the xml
- for the Cache implementation. In addition, there is another <literal>jboss-aop.xml</literal>
- for some customized behaviors (if needs to).
- Finally, how do we deal with the PojoCache bean service?</para>
+ for the Cache implementation. In addition, there is another <literal>pojocache-aop.xml</literal>
+ for some customized behaviors (if needs to).</para>
+
+ <sect1>
+ <title>Cache configuration xml file</title>
+ <para>When a user obtains a PojoCache instance from the PojoCacheFactory, it requires user pass in
+ a configuration xml file. PojoCache will simply pass this xml to the underlying Cache implementation.
+ As a result, any state replication aspects can be configured in this file, along with cache
+ passivation. For details on the configuration xml, you can check out the core Cache documentation.</para>
+ </sect1>
+
+ <sect1>
+ <title>Passivation configuration</title>
+ <para>A user can also configure the underlying Cache to activate the passivation. Passivation is feature
+ needed to keep the VM memory compact. In JBoss Cache, it is done via combincation of eviction
+ policy and cache loader. That is, when a node is evicted from Cache, it will store into the cache
+ loader. When the node is requested again, it will be loaded from the store and stored into memory.
+ Below is a snippet from a cache configuration xml
+ illustrating how the eviction policy along with cache loader can be configured. Please note that this is
+ simply an aspect of the underlying Cache. That is, PojoCache layer is agnostic to this behavior.
+<programlisting>
+<attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
+<attribute name="EvictionPolicyConfig">
+ <config>
+ <attribute name="wakeUpIntervalSeconds">5</attribute>
+ <!-- Cache wide default -->
+ <region name="/_default_">
+ <attribute name="maxNodes">5000</attribute>
+ <attribute name="timeToLiveSeconds">3</attribute>
+ </region>
+ <region name="/org/jboss/test/data">
+ <attribute name="maxNodes">100</attribute>
+ <attribute name="timeToLiveSeconds">3</attribute>
+ </region>
+ </config>
+</attribute>
+
+<attribute name="CacheLoaderConfiguration">
+ <config>
+ <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
+ <passivation>true</passivation>
+ <preload>/</preload>
+ <shared>false</shared>
+
+ <!-- we can now have multiple cache loaders, which get chained -->
+ <cacheloader>
+ <class>org.jboss.cache.loader.FileCacheLoader</class>
+ <!-- whether the cache loader writes are asynchronous -->
+ <async>false</async>
+ <!-- only one cache loader in the chain may set fetchPersistentState to true.
+ An exception is thrown if more than one cache loader sets this to true. -->
+ <fetchPersistentState>true</fetchPersistentState>
+ <!-- determines whether this cache loader ignores writes - defaults to false. -->
+ <ignoreModifications>false</ignoreModifications>
+ </cacheloader>
+ </config>
+</attribute>
+
+</programlisting>
+ </para>
+ </sect1>
+
+
+ <sect1>
+ <title>PojoCache configuration xml</title>
+ <para>PojoCache supplies a <literal>pojocache-aop.xml</literal> that is required to be set via a
+ system property: <literal>jboss.aop.path</literal> during compile- or load-time. The file now consists
+ of interceptor stack specification and annotations for POJO instrumentation. It is listed fully in the
+ Appendix section. Note that the file should be read mostly. So no need to modify it now unless you
+ are customizing the interceptor chain, e.g.</para>
+ </sect1>
<sect1>
<title>PojoCache MBean service</title>
- <para>PojoCache can also be deployed as a MBean service under JBoss
- Application Server. However, you will need to use the correct class to
- instantiate. For example, this is the code snippet for the MBean
- attribute in the xml file:
- <programlisting><mbean code="org.jboss.cache.aop.PojoCache" name="jboss.cache:service=PojoCache"></programlisting>
- You can modify the object service name to your liking, of course.
+ <para>PojoCache can expose the MBean attributes by setting the flag <literal>useMBean</literal>
+ in the cache config xml.
</para>
</sect1>
1.3 +39 -167 JBossCache/docs/PojoCache/en/modules/instrumentation.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: instrumentation.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/instrumentation.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -b -r1.2 -r1.3
--- instrumentation.xml 28 Apr 2006 08:37:07 -0000 1.2
+++ instrumentation.xml 27 Sep 2006 06:49:42 -0000 1.3
@@ -3,22 +3,21 @@
<title>Instrumentation</title>
<para>In this chapter, we explain how to instrument (or "aspectize") the
- POJOs via JBossAop. There are two steps needed by JBossAop: 1) POJO
- declaration, 2) instrumentation. But depends on the JDK and instrumentation
+ POJOs via JBoss Aop. There are two steps needed by JBoss Aop: 1) POJO
+ declaration, 2) instrumentation. But depends on the instrumentation
mode that you are using, you may not need to pre-process your POJO at all. That is,
- if you use JDK5.0 and load-time mode, then all you need to do is
- annotation your POJO (or declare it in a xml file). This makes your PojoCache
+ if you use JDK5.0 (required) and load-time mode, then all you need to do is
+ annotating your POJO (or declare it in a xml file). This makes your PojoCache
programming nearly transparent.</para>
<para>For the first step, since we are using the dynamic Aop feature, a
POJO is only required to be declared "prepare". Basically, there are two
- ways to do this: either via explicit xml or annotation (new since release
- 1.2.3.)</para>
+ ways to do this: either via explicit xml or annotation.</para>
- <para>As for the second step, either we can ask JBossAop to do load-time
- (through a special class loader, so-called loadtime mode) or compile-time
+ <para>As for the second step, either we can ask JBoss Aop to do load-time
+ (through a special class loader, so-called load-time mode) or compile-time
instrumentation (use of an aopc pre-compiler, so-called precompiled
- mode)</para>
+ mode). Read can read the JBoss Aop introduction chapter for more details.</para>
<sect1>
<title>XML descriptor</title>
@@ -26,18 +25,19 @@
<para>To declare a POJO via XML configuration file, you will need a
<literal>META-INF/jboss-aop.xml</literal>
file located under the class
- path. JBossAOP framework will read this file during startup to make
+ path or a <literal>xxx-aop.xml</literal> listed in the <literal>jboss.aop.path</literal> system
+ property. JBoss AOP framework will read this file during startup to make
necessary byte code manipulation for advice and introduction. Or you
can pre-compile it using a pre-compiler called
<literal>aopc</literal>
- such that you won't need the XML file during load time. JBossAop
+ such that you won't need the XML file during load time. JBoss Aop
provides a so-called
<literal>pointcut</literal>
language where it
consists of a regular expression set to specify the interception
points (or
<literal>jointpoint</literal>
- in aop language). The
+ in aop parlance). The
jointpoint can be constructor, method call, or field. You will need to
declare any of your POJO to be "prepared" so that AOP framework knows
to start intercepting either method, field, or constructor invocations
@@ -49,10 +49,10 @@
for the method level interception since it is the state that we are
interested in. So you should
only need to change your POJO class name. For details of the pointcut
- language, please refer to JBossAop.</para>
+ language, please refer to JBoss Aop.</para>
<para>The standalone
- <literal>JBossCache</literal>
+ <literal>JBoss Cache</literal>
distribution
package provides an example declaration for the tutorial classes,
namely,
@@ -106,46 +106,30 @@
operator declares any sub-type or sub-class of the specific POJO will also be "aspectized". For
example, if a
-
<code>Student</code>
-
class is a subclass of
-
<code>Person</code>
-
, JBossAop will automatically instrument it as well!
</listitem>
<listitem>
We intercept the field of all access levels (i.e.,
-
<literal>private</literal>
-
,
-
<literal>protected</literal>
-
,
-
<literal>public</literal>
-
, etc.) The main reason being that we consider all fields as stateful data. However, we can relax this
requirement in the future if there is a use case for it.
</listitem>
<listitem>
We don't intercept field modifiers of
-
<literal>static</literal>
-
,
-
<literal>final</literal>
-
, and
-
<literal>transient</literal>
-
though. That is, field with these modifiers are not stored in cache and is not replicated either. If
you don't want your field to be managed by the cache, you can declare them with these modifiers, e.g.,
transient.
@@ -154,52 +138,27 @@
</sect1>
<sect1>
-
-
<title>Annotation</title>
-
-
<para>Annotation is a new feature in Java 5.0 that when declared can
contain metadata at compile and run time. It is well suited for aop
declaration since there will be no need for external metadata xml
- descriptor. In order to support Java 1.4 as well, JBossAop has also used a xdoclet
- type annotation syntax, and as a result will need an annotation
- pre-compiler.</para>
-
+ descriptor.</para>
- <para>Note that PojoCache starts to support the use of annotation since
- release 1.2.3 with Java 1.4, and release 1.3 with Java 5.0.
- </para>
<sect2>
- <title>JDK1.4</title><para>
- In order to provide maximum transparency,
- we have created two aop marker interfaces:
- <code>@@org.jboss.cache.aop.AopMarker</code>
- and
- <code>@@org.jboss.cache.aop.InstanceOfAopMarker.</code>
- The first
- interface is used to declare a regular POJO, while the latter one is
- used to declare the POJO and its sub-classes or sub-types.
- </para>
-
-
- <para>Finally, to support annotation (to
- simplify user's development effort), the JBossCache distribution ships with a
- <literal>jboss-aop.xml</literal>
+ <title>POJO annotation for instrumentation</title>
+ <para>To support annotation (in order to
+ simplify user's development effort), the JBoss Cache distribution ships with a
+ <literal>pojocache-aop.xml</literal>
under the
<literal>resources</literal>
- directory. When you use the annotation
- precompiler, this file needs to be in the class path. For example,
- please refer to the
- <literal>annoc</literal>
- Ant build target. For
- reference, here is the content of that
- <literal>jboss-aop.xml</literal>
+ directory. For
+ reference, here is annotation definition from
+ <literal>pojocache-aop.xml</literal>
:
<programlisting>
<aop>
- <prepare expr="field(* @@org.jboss.cache.aop.AopMarker->*)" />
- <prepare expr="field(* $instanceof{@@org.jboss.cache.aop.InstanceOfAopMarker}->*)" />
+ <prepare expr="field(* @org.jboss.cache.pojo.annotation.PojoCacheable->*)" />
+ <prepare expr="field(* $instanceof{@@org.jboss.cache.pojo.annotation.InstanceOfPojoCacheable}->*)" />
</aop>
</programlisting>
Basically, it simply states that any annotation
@@ -208,60 +167,34 @@
<para>Here is two code snippets that illustrate the declaration of
- both types through 1.4 style annotation:</para>
+ both types:</para>
<programlisting>
-/**
-* @@org.jboss.cache.aop.AopMarker
-*/
+ at org.jboss.cache.pojo.annotation.PojoCacheable
public class Address {...}
</programlisting>
The above declaration will instrument the class <literal>Address</literal>, and
<programlisting>
-/**
-* @@org.jboss.cache.aop.InstanceOfAopMarker
-*/
+ at org.jboss.cache.pojo.annotation.InstanceOfPojoCacheable
public class Person {...}
</programlisting>
The above declaration will instrument the class <literal>Person</literal> and all of its sub-classes. That is, if
<literal>Student</literal> sub-class from <literal>Personal</literal>, then it will get instrumented automatically without
further annotation declaration.
-
-
- <para>Note that the simplicity of declaring POJOs through annotation
- and its marker interfaces (although you will need to use the
- annotation pre-compiler.) See the build.xml target
- <code>annoc</code>
- for example.
- </para>
-</sect2>
-
- <sect2>
- <title>JDK5.0</title>
- <para>The JDK5.0 annotation is similar to the JDK1.4 counterpart except the annotation names themselves
- are different, e.g., the two annotations are:
- <code>@org.jboss.cache.aop.annotation.PojoCacheable</code>
- and
- <code>@org.jboss.cache.aop.annotation.InstanceOfPojoCacheable.</code>
- For example, when using JDK5.0 annotation, instead of using <code>@@org.jboss.cache.aop.AopMarker</code>
- you will use <code>@org.jboss.cache.aop.annotation.PojoCacheable</code> instead. In the distribution, under
- <code>examples/PojoCache/annotated50</code>, there is an example of using JDK50 annotation. Note that we have
- decided to use different annotation naming convention between JDK1.4 and 5.0.
- </para>
</sect2>
<sect2>
<title>JDK5.0 field level annotations</title>
- <para>In Release 1.4, we have added two additional field level annotations for customized behavior.
- The first one is <code>@org.jboss.cache.aop.annotation.Transient</code>. When applied to a field
+ <para>In Release 2.0, we have added two additional field level annotations for customized behavior.
+ The first one is <code>@org.jboss.cache.pojo.annotation.Transient</code>. When applied to a field
variable, it has the same effect as the Java language <code>transient</code> keyword. That is, PojoCache
won't put this field into cache management (and therefore no replication).
</para>
<para>
- The second one is <code>@org.jboss.cache.aop.annotation.Serializable</code>, when applied to a field
+ The second one is <code>@org.jboss.cache.pojo.annotation.Serializable</code>, when applied to a field
varaiable, PojoCache will treat this variable as <code>Serializable</code>, even when it is
<code>PojoCacheable</code>. However, the field will need to implement the <code>Serializable</code>
interface such that it can be replicated.
@@ -331,55 +264,18 @@
<sect2>
<title>Ant target for running load-time instrumentation using specialized class loader</title>
- <para>Below is the code snippet for the Ant target that is doing loadtime instrumentation through a special
- classloader. Basically, the Ant target <literal>one.test.aop</literal> using the bootclass loader generated
- by the Ant target <literal>generateClassLoader</literal> to run an individual test.
- Note that since JBossAop 1.3, a new <literal>GenerateInstrumentedClassLoader</literal>
- has been used since the previous <literal>SystemClassLoader</literal> is error prone.</para>
-<programlisting>
- <target name="generateClassLoader" description=
- "Generate a new modified class loader so we can perform load time instrumentation">
- <property name="build.bootclasspath" value="${output}/gen-bootclasspath"/>
- <java classname="org.jboss.aop.hook.GenerateInstrumentedClassLoader">
- <classpath>
- <path refid="aop.classpath"/>
- </classpath>
- <arg value="${build.bootclasspath}"/>
- </java>
- <path id="bootclasspath">
- <pathelement location="${build.bootclasspath}"/>
- <path refid="aop.classpath"/>
- </path>
- <property name="bootclasspath" refid="bootclasspath"/>
- </target>
-
- <!-- eg. ant run.examples -Dtest=org.jboss.test.cache.test.local.NoTxUnitTestCase -->
- <target name="one.test.aop" depends="compile, generateClassLoader" description="run one junit test case.">
- <junit printsummary="yes" timeout="${junit.timeout}" fork="yes">
- <jvmarg value="-Djboss.aop.path=${output}/etc/META-INF/jboss-aop.xml"/>
- <jvmarg value="-Xbootclasspath/p:${bootclasspath}"/>
- <!-- jvmarg value="-Dbind.address=${bind.address}"/ -->
- <classpath path="${output}/etc" />
- <sysproperty key="log4j.configuration" value="file:${output}/etc/log4j.xml" />
- <classpath refid="lib.classpath"/>
- <classpath path="${build}"/>
- <formatter type="xml" usefile="true"/>
- <test name="${test}" todir="${reports}"/>
- </junit>
- </target>
-</programlisting>
<para>
- If you are running JDK5.0, you can also use the <code>javaagent</code> option that does not require a
- separate Classloader. Here are the ant snippet from <code>one-test-aop50</code>, for example.
+ In JDK5.0, you can use the <code>javaagent</code> option that does not require a
+ separate Classloader. Here are the ant snippet from <code>one-test-pojo</code>, for example.
<programlisting>
- <target name="one.test.aop50" depends="compile, generateClassLoader" description="run one junit test case.">
+ <target name="one.test.pojo" depends="compile" description="run one junit test case.">
<junit printsummary="yes" timeout="${junit.timeout}" fork="yes">
- <jvmarg value="-Djboss.aop.path=${output}/resources/jboss-aop.xml"/>
- <jvmarg value="-javaagent:${lib-50}/jboss-aop-jdk50.jar"/>
+ <jvmarg value="-Djboss.aop.path=${output}/resources/pojocache-aop.xml"/>
+ <jvmarg value="-javaagent:${lib}/jboss-aop-jdk50.jar"/>
<classpath path="${output}/etc" />
<sysproperty key="log4j.configuration" value="file:${output}/etc/log4j.xml" />
- <classpath refid="lib.classpath.50"/>
- <classpath refid="build.classpath.50"/>
+ <classpath refid="lib.classpath"/>
+ <classpath refid="build.classpath"/>
<formatter type="xml" usefile="true"/>
<test name="${test}" todir="${reports}"/>
</junit>
@@ -398,7 +294,7 @@
<aopc compilerclasspathref="aop.classpath" verbose="true">
<src path="${build}"/>
<include name="org/jboss/cache/aop/test/**/*.class"/>
- <aoppath path="${output}/etc/META-INF/jboss-aop.xml"/>
+ <aoppath path="${output}/resources/pojocache-aop.xml"/>
<classpath path="${build}"/>
<classpath refid="lib.classpath"/>
</aopc>
@@ -419,30 +315,6 @@
</figure>
</sect2>
-
- <sect2>
- <title>Ant target for annotation compiler</title>
- <para>Below is the code snippet for the <literal>annoc</literal> Ant target. You run this step if you are using
- the JDK1.4 annotation. After this step is successfully run, you decide either to use compile-time or load-time mode
- of weaving.</para>
-<programlisting>
- <!-- pre-compile directory with annotationc using jdk1.4 -->
- <target name="annoc" depends="compile" description="Annotation precompiler for aop class">
- <!-- Define a new ant target. This is the 1.4 annotation pre-compiler. After running this step,
- you still need to run the aopc step again, if you are not using system class loader.
- -->
- <taskdef name="annotationc" classname="org.jboss.aop.ant.AnnotationC" classpathref="aop.classpath"/>
- <annotationc compilerclasspathref="aop.classpath" bytecode="true">
- <classpath refid="lib.classpath"/>
- <classpath path="${build}"/>
- <!--System wide jboss-aop.xml is located here. -->
- <classpath path="${output.resources.dir}"/>
- <src path="${source}"/>
- <include name="org/jboss/cache/aop/test/**/*.java"/>
- </annotationc>
- </target>
-</programlisting>
- </sect2>
</sect1>
More information about the jboss-cvs-commits
mailing list