[jboss-cvs] JBossAS SVN: r62849 - in projects/aop/trunk/aop/docs: examples and 40 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon May 7 17:27:26 EDT 2007
Author: kabir.khan at jboss.com
Date: 2007-05-07 17:27:26 -0400 (Mon, 07 May 2007)
New Revision: 62849
Removed:
projects/aop/trunk/aop/docs/examples/after-throwing/after-throwing.wiki
projects/aop/trunk/aop/docs/examples/all/all.wiki
projects/aop/trunk/aop/docs/examples/annotated-aspects/annotated-aspects.wiki
projects/aop/trunk/aop/docs/examples/annotated-cflow/annotated-cflow.wiki
projects/aop/trunk/aop/docs/examples/annotated-composition/annotated-composition.wiki
projects/aop/trunk/aop/docs/examples/annotated-declare/annotated-declare.wiki
projects/aop/trunk/aop/docs/examples/annotated-dynamic-cflow/annotated-dynamic-cflow.wiki
projects/aop/trunk/aop/docs/examples/annotated-injboss/annotated-injboss.wiki
projects/aop/trunk/aop/docs/examples/annotated-interceptors/annotated-interceptors.wiki
projects/aop/trunk/aop/docs/examples/annotated-introduction/annotated-introduction.wiki
projects/aop/trunk/aop/docs/examples/annotated-parameters/annotated-parameters.wiki
projects/aop/trunk/aop/docs/examples/annotated-precedence/annotated-precedence.wiki
projects/aop/trunk/aop/docs/examples/annotated-typedef/annotated-typedef.wiki
projects/aop/trunk/aop/docs/examples/annotation-introductions/annotation.wiki
projects/aop/trunk/aop/docs/examples/annotation/annotation.wiki
projects/aop/trunk/aop/docs/examples/annotation14/annotation.wiki
projects/aop/trunk/aop/docs/examples/aspect/aspect.wiki
projects/aop/trunk/aop/docs/examples/beanstyleconf/config.wiki
projects/aop/trunk/aop/docs/examples/beforeafter/beforeafter.wiki
projects/aop/trunk/aop/docs/examples/caller/caller.wiki
projects/aop/trunk/aop/docs/examples/cflow/cflow.wiki
projects/aop/trunk/aop/docs/examples/composition/composition.wiki
projects/aop/trunk/aop/docs/examples/constructor-execution/constructor.wiki
projects/aop/trunk/aop/docs/examples/declare/declare.wiki
projects/aop/trunk/aop/docs/examples/dynamic-aop/dynamic.wiki
projects/aop/trunk/aop/docs/examples/dynamic_cflow/cflow.wiki
projects/aop/trunk/aop/docs/examples/examples.wiki
projects/aop/trunk/aop/docs/examples/field-execution/field.wiki
projects/aop/trunk/aop/docs/examples/implements/implements.wiki
projects/aop/trunk/aop/docs/examples/injboss/aopInJbossPackaging.wiki
projects/aop/trunk/aop/docs/examples/instanceof/instanceof.wiki
projects/aop/trunk/aop/docs/examples/introductions/introductions.wiki
projects/aop/trunk/aop/docs/examples/ioc_with_has/has.wiki
projects/aop/trunk/aop/docs/examples/metadata/metadata.wiki
projects/aop/trunk/aop/docs/examples/method-execution/methodexecution.wiki
projects/aop/trunk/aop/docs/examples/overloaded-advices/overloaded-advices.wiki
projects/aop/trunk/aop/docs/examples/packaging/packaging.wiki
projects/aop/trunk/aop/docs/examples/precedence/precedence.wiki
projects/aop/trunk/aop/docs/examples/stacks/stacks.wiki
projects/aop/trunk/aop/docs/examples/typedef/typedef.wiki
projects/aop/trunk/aop/docs/index.wiki
projects/aop/trunk/aop/docs/misc/debugging_analysis.wiki
projects/aop/trunk/aop/docs/misc/invocation.wiki
projects/aop/trunk/aop/docs/misc/joinpoint.wiki
projects/aop/trunk/aop/docs/misc/non_pointcutable.wiki
projects/aop/trunk/aop/docs/misc/reflection.wiki
Log:
Get rid of the unused .wiki files
Deleted: projects/aop/trunk/aop/docs/examples/after-throwing/after-throwing.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/after-throwing/after-throwing.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/after-throwing/after-throwing.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,93 +0,0 @@
-!!!After Throwing Advices
-
-!Overview
-Besides before, after and around advices, you can also write after-throwing advices.
-These advices intercept joinpoints throwing an exception. In this example, we will see
-how to write that type of advices.
-
-!Writing After Throwing Advices
-
-
-After-throwing advices are written using the annotated parameter signature.
-The only difference is that these advices feature an additional annotated parameter:
-{{@Thrown}}. This mandatory parameter will hold the thrown exception.
-So, an after-throwing advice should be of the form:
-
-{{{
-public void <any-method-name>(@Thrown Throwable arg0, @<Annotation> <any type> arg1, @<Annotation> <any type> arg1, ... , @<Annotation> <any type> argN) throws <Exception1>,<Exception2>,...,<ExceptionN>
-}}}
-
-!Binding After Throwing Advices
-
-To bind an after throwing advice to a pointcut, simply insert the {{<throwing>}} tag
-in a binding xml declaration, as in the following example:
-
-{{{
-<bind pointcut="execution(* POJO->*(..))">
- <throwing name="afterThrowing" aspect="Aspect"/>
-</bind>
-}}}
-
-Differently from other advice types, after-throwing advices aren't called everytime
-an intercepted joinpoint gets executed. On the contrary, after-throwing advices are
-invoked only when the joinpoint throws an exception. So, in the binding example
-above, this means that {{afterThrowing}} will be invoked only after a {{POJO}} method
-throws an exception, instead of being invoked after all {{POJO}} methods' executions.
-
-!Examples
-
-You can find examples of after-throwing advices in the {{Aspect.java}} file.
-
-The following advice signature:
-{{{
-public void afterThrowing(@Thrown Throwable thrown)
-}}}
-
-Is the simplest you can write, since the {{@Thrown Throwable}} parameter is mandatory.
-
-But you can also include any other
-[annotated parameter|../annotated-parameters/annotated-parameters.html] (except
-{{@Return}}, which is exclusive of after advices).
-
-The following advice signature is valid to intercept a method execution throwing an
-exception:
-{{{
-public void afterThrowingInfo(@JoinPoint IMethodInfo methodInfo, @Thrown Throwable thrown)
-}}}
-
-Notice that you can declare the annotated parameters in any order you wish.
-
-If the method being intercepted receives an {{String}} argument, these after throwing
-signatures are also valid:
-
-{{{
-public void afterThrowingArg(@Thrown Throwable thrown, @Arg String argument)
-public void afterThrowingInfoArg(@Thrown Throwable thrown, @JoinPoint IMethodInfo methodInfo, @Arg String argument)
-}}}
-
-
-!Run the example
-
-__THIS EXAMPLE REQUIRES JDK 1.5!!__ To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode,
-then finally run the example. The output should read as follows:
-{{{
-run:
-
- [java] Calling POJO->throwExceptionMethod()
- [java] ====================================
- [java] RUNNING POJO->throwsExceptionMethod("argument")
- [java] >>> afterThrowing: java.lang.Exception: POJO Exception
- [java] >>> afterThrowingInfo: java.lang.Exception: POJO Exception
- [java] >>> afterThrowingArg: java.lang.Exception: POJO Exception
- [java] >>> afterThrowingInfoArg: java.lang.Exception: POJO Exception
- [java] Caching Exception java.lang.Exception: POJO Exception
-
- [java] Calling POJO->throwNothingMethod()
- [java] ==================================
- [java] RUNNING POJO->throwNothingMethod()
- [java] No Exception this time
-}}}
Deleted: projects/aop/trunk/aop/docs/examples/all/all.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/all/all.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/all/all.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,36 +0,0 @@
-!!!Intercept everything
-
-!All
-The ''all'' pointcut expression matches any constructor, method, or field execution of a particular class expression.
-{{{
-<aop>
- <bind pointcut="all(POJO)">
- <interceptor class="SimpleInterceptor"/>
- </bind>
-</aop>
-}}}
-The SimpleInterceptor will be called for the constructor, method, and field access in {{Driver.java}}
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] <<< Entering SimpleInterceptor type: org.jboss.aop.joinpoint.ConstructorInvocation
- [java] empty constructor
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.someMethod(); ---
- [java] <<< Entering SimpleInterceptor type: org.jboss.aop.joinpoint.MethodInvocation
- [java] someMethod
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.var++; ---
- [java] <<< Entering SimpleInterceptor type: org.jboss.aop.joinpoint.FieldReadInvocation
- [java] >>> Leaving SimpleInterceptor
- [java] <<< Entering SimpleInterceptor type: org.jboss.aop.joinpoint.FieldWriteInvocation
- [java] >>> Leaving SimpleInterceptor
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-aspects/annotated-aspects.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-aspects/annotated-aspects.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-aspects/annotated-aspects.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,80 +0,0 @@
-!!!Annotated Aspects
-
-!Overview
-Just like interceptors you write the code for an aspect class in exactly the same way when you are using annotated bindings as you would if you were using an xml file to declare them.
-To recap: an aspect class is a plain Java class. It does not have to inherit from anything, but it must have an empty constructor. Each advice must follow this format:
-
-{{{
- public Object <any-method-name>(<any Invocation type>) Throwable
-}}}
-
-!Declaring and binding the Aspects
-
-Open up {{MyAspect}}, and you will see that the class itself is normal, but that the class has been annotated as follows:
-
-{{{
- import org.jboss.aop.Bind;
- import org.jboss.aop.Aspect;
-
- @Aspect
- public class MyAspect
- {
- @Bind (pointcut="execution(POJO->new())")
- public Object constructorAdvice(ConstructorInvocation invocation) throws Throwable
- {
- ...
- }
-
- @Bind (pointcut="execution(void POJO->method())")
- public Object methodAdvice(MethodInvocation invocation) throws Throwable
- {
- ...
- }
-
- @Bind (pointcut="set(int POJO->field)")
- public Object fieldAdvice(FieldReadInvocation invocation) throws Throwable
- {
- ...
- }
-
- @Bind (pointcut="get(int POJO->field)")
- public Object fieldAdvice(FieldWriteInvocation invocation) throws Throwable
- {
- ...
- }
- }
-}}}
-
-The class itself is annotated with {{@Aspect}}, this declares the class as an aspect in JBoss AOP. Next each of the advice methods has been annotated with {{@Bind}}, this binds each method to the specified pointcut. So,
-
-* Executions of POJO's empty constructor get intercepted by {{MyAspect.constructorAdvice()}}
-* Executions of {{POJO.method()}} get intercepted by {{MyAspect.methodAdvice() }}
-* reads of {{POJO.field}} get intercepted by {{MyAspect.fieldAdvice()}} (FieldReadInvocation version)
-* writes to {{POJO.field}} get intercepted by {{MyAspect.fieldAdvice()}} (FieldWriteInvocation version)
-
-
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo constructor ---
- [java] <<< MyAdvice.constructorAdvice accessing: public POJO()
- [java] constructor
- [java] >>> Leaving MyAdvice.constructorAdvice
- [java] --- pojo.method(); ---
- [java] <<< MyAdvice.methodAdvice accessing: public void POJO.method()
- [java] method()
- [java] >>> Leaving MyAdvice.methodAdvice
- [java] --- pojo field write ---
- [java] <<< MyAspect.fieldAdvice reading field: field
- [java] >>> Leaving MyAspect.fieldAdvice
- [java] --- pojo field read ---
- [java] <<< MyAspect.fieldAdvice writing to field: field
- [java] >>> Leaving MyAspect.fieldAdvice
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-cflow/annotated-cflow.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-cflow/annotated-cflow.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-cflow/annotated-cflow.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,79 +0,0 @@
-!!!Annotated Control Flow
-
-!Overview
-The principles behind CFlow when using annotations is exactly the same as when using [XML|cflow/cflow.html], all that is different is the way of defining it.
-
-!@CFlowStackDef and @CFlowDef
-MyAspect contains a few @CFlowStackDef annotated fields:
-
-{{{
- @CFlowStackDef (cflows={@CFlowDef(expr = "void POJO->method1()", called=true), @CFlowDef(expr = "void POJO->method2()", called=true), @CFlowDef(expr = "void POJO->method3()", called=true)})
- public static CFlowStack cf123Before;
-}}}
-
-The first one declares that method1, method2, and method3 should be in the call stack in that order. The next
-{{{
- @CFlowStackDef (cflows={@CFlowDef(expr = "POJO->new()", called=true), @CFlowDef(expr = "void POJO->method3()", called=true)})
- public static CFlowStack cf1ConAnd3;
-}}}
-Says that the POJO constructor with an int parameter and method3 must be in the call stack in that order. As for [Annotated composition|../annotated-composition/annotated-composition.html] and [Annotated typedefs|../annotated-typedef/annotated-typedef.html] the fully qualified name of the {{@CFlowStackDef}} annotated field is used when we reference the CFlowStackDef by name. Again, the type {{CFlowStack}} is used as the type of the field for clarity, even though the actual type of the field is irrelevant.
-
-!Apply a @CFlowStackDef
-You can reference the CFlowStackDef from within a {{@Bind}} annotation, by using the name of the field that was annotated. They can be compositional as well. The following binding in MyAspect uses the defined CFlowStackDefs
-
-{{{
- @Bind (pointcut="execution(void POJO->method4())", cflow="(MyAspect.cf123Before OR MyAspect.cf123Before)")
- public Object methodAdvice(MethodInvocation invocation) throws Throwable
- {
- ...
- }
-
-}}}
-This says to trigger the SimpleInterceptor on the execution of method4, but only when it is called within the context of method1, method2, and method3 OR contructor and method3.
-
-The next example in MyAspect is for recursive methods. The example CFlowStackDef says that two calls to the recursive method must be in the call stack, but no more
-{{{
- @CFlowStackDef (cflows={@CFlowDef(expr = "void POJO->recursive(int)", called=true), @CFlowDef(expr = "void POJO->recursive(int)", called=true), @CFlowDef(expr = "void POJO->recursive(int)", called=false)})
- public static CFlowStack cf2Recursions;
-
- @Bind (pointcut="execution(void POJO->recursive(int))", cflow="MyAspect.cf2Recursions")
- public Object recursiveAdvice(MethodInvocation invocation) throws Throwable
- {
- ...
- }
-}}}
-
-Combined with the execution binding, the SimpleInterceptor will only be triggered on the second call to the recursive method.
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo.method4(); ---
- [java] method4
- [java] --- pojo.method3(); ---
- [java] method3
- [java] method4
- [java] --- pojo.method2(); ---
- [java] method2
- [java] method3
- [java] method4
- [java] --- pojo.method1(); ---
- [java] method1
- [java] method2
- [java] method3
- [java] <<< MyAdvice.methodAdvice accessing: public void POJO.method4()
- [java] method4
- [java] >>> Leaving MyAdvice.methodAdvice
- [java] --- pojo.recursive(); ---
- [java] recursive: 1
- [java] recursive: 2
- [java] recursive: 3
- [java] --- new POJO(int); ---
- [java] method3
- [java] method4
-}}}
Deleted: projects/aop/trunk/aop/docs/examples/annotated-composition/annotated-composition.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-composition/annotated-composition.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-composition/annotated-composition.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,81 +0,0 @@
-!!!Annotated: Compositional and Named Pointcuts
-
-Just as when defining pointcuts in [XML|../composition/composition.html], you can use named pointcuts when defining the AOP bindings using annotations.
-
-!Examples
-Let's take a look at {{MyAspect.java}}
-
-{{{
- import org.jboss.aop.Bind;
- import org.jboss.aop.Aspect;
- import org.jboss.aop.PointcutDef;
- import org.jboss.aop.pointcut.Pointcut;
- import org.jboss.aop.pointcut.Pointcut;
-
- @Aspect (scope=Scope.PER_VM)
- public class MyAspect
- {
- @PointcutDef("execution(POJO->new(..))")
- public static Pointcut pojoConstructors;
-
- @PointcutDef("get(* POJO->*)")
- public static Pointcut pojoFieldReads;
-
- @PointcutDef("set(* POJO->*)")
- public static Pointcut pojoFieldWrites;
-
- @PointcutDef("execution(* POJO->*(..))")
- public static Pointcut pojoMethods;
-}}}
-The {{@PointcutDef}} annotations create a named pointcut, so we get:
-
-*one matching exexutions of all constructors on the POJO class.
-*one matching exexutions of all methods on the POJO class.
-*one matching the reads of all fields in the POJ0 class
-*one matching the writes of all fields in the POJ0 class
-
-The name of the annotated field becomes the name of the annotated field and is used when you reference the field. Note that for clarity we use {{org.jboss.aop.pointcut.Pointcut}} as the type of our field, but any type can be used.
-
-Below we use composition to create a pointcut by referencing the two named pointcuts. As mentioned we reference them by the fully qualified names of the fields annotated with @PointcutDef
-{{{
- @PointcutDef("MyAspect.pojoFieldReads OR MyAspect.pojoFieldWrites")
- public static Pointcut pojoFields;
-
- @Bind(pointcut = "MyAspect.pojoFields OR MyAspect.pojoMethods OR MyAspect.pojoConstructors")
-
- public Object anotherPOJOAdvice(Invocation invocation) throws Throwable
- {
- ...
- }
-
- }//End - class MyAspect
-}}}
-
-
-!Running the example
-Running the example you'll see composition in action
-
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo constructor ---
- [java] <<< MyAspect.anotherPOJOAdvice - calling constructor
- [java] constructor
- [java] >>> Leaving MyAspect.anotherPOJOAdvice
- [java] --- pojo.method(); ---
- [java] <<< MyAspect.anotherPOJOAdvice - calling method
- [java] method()
- [java] >>> Leaving MyAspect.anotherPOJOAdvice
- [java] --- pojo field write ---
- [java] <<< MyAspect.anotherPOJOAdvice - writing field
- [java] >>> Leaving MyAspect.anotherPOJOAdvice
- [java] --- pojo field read ---
- [java] <<< MyAspect.anotherPOJOAdvice - reading field
- [java] >>> Leaving MyAspect.anotherPOJOAdvice
-
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-declare/annotated-declare.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-declare/annotated-declare.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-declare/annotated-declare.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,257 +0,0 @@
-!!! Annotated Declare Error/Warning
-
-The principles behind declare error/warning, and the example used here is exactly the same as in the [XML|../declare/declare.html] example. But the errors/warnings are declared differently using annotations.
-
-!! Declaring warnings
-To declare a warning, you annotate a field with {{@DeclareWarning}}. This field must be within an {{@Aspect}} or {{@InterceptorDef}} annotated class. The type of the field does not actually matter, though Pointcut has been used in this example. {{DeclareAspect}} is not actually bound to anything and does no interceptions, its sole purpose in this example is as a vessel for the {{@DeclareWarning}} annotations.
-
-{{{
- import org.jboss.aop.DeclareWarning;
-
- @Aspect
- public class DeclareAspect
- {
- @DeclareWarning (expr="class($instanceof{VehicleDAO}) AND !has(public void *->save())", msg="All VehicleDAO subclasses must override the save() method.")
- public static Pointcut warning1;
-
- @DeclareWarning (expr="call(Driver->new(..)) AND within(*DAO)", msg="DAO classes should not access the Driver class")
- public static Pointcut warning2;
-
- @DeclareWarning (expr="call(* Driver->*(..)) AND withincode(* *DAO->save())", msg="DAO classes should not access the Driver class")
- public static Pointcut warning3;
- }
-}}}
-
-*The first {{@DeclareWarning}} annotated field specifies that {{VehicleDAO}} and its subclasses must implement a void noargs save() method. This condition is broken in our example by the fact that {{MotorbikeDAO}} does not do so.
-*The second {{@DeclareWarning}} annotated field specifies that none of the DAO classes can call the Driver constructor. This condition is broken in our example by the fact that {{CarDAO.save()}} tries to create a new {{Driver}} class.
-*The third {{@DeclareWarning}} annotated field specifies that no method on any of the the DAO classes can call the Driver methods. This condition is broken in our example by the fact that {{CarDAO.save()}} tries to call a method on the {{Driver}} class
-
-!! Declaring errors
-You declare an error in the same way as a warning, but you use the {{@DeclareError}} annotation instead. Modify {{DeclareAspect}} so that it becomes:
-
-{{{
- import org.jboss.aop.DeclareError;
- import org.jboss.aop.Aspect;
- import org.jboss.aop.pointcut.Pointcut;
-
- @Aspect
- public class DeclareAspect
- {
- @DeclareError (expr="class($instanceof{VehicleDAO}) AND !has(public void *->save())", msg="All VehicleDAO subclasses must override the save() method.")
- public static Pointcut warning1;
-
- @DeclareError (expr="call(Driver->new(..)) AND within(*DAO)", msg="DAO classes should not access the Driver class")
- public static Pointcut warning2;
-
- @DeclareError (expr="call(* Driver->*(..)) AND withincode(* *DAO->save())", msg="DAO classes should not access the Driver class")
- public static Pointcut warning3;
- }
-
-}}}
-
-!Run the example compile-time instrumented
-
-Now if you run the example:
-
-To compile and run:
-{{{
- $ ant
-}}}
-
-It will generate the following output
-{{{
-Buildfile: build.xml
-
-prepare:
-
-compile:
- [aopc] WARNING: declare-warning condition
- [aopc] 'call(Driver->new(..)) AND within(*DAO)'
- [aopc] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] WARNING: declare-warning condition
- [aopc] 'call(* Driver->*(..)) AND withincode(* *DAO->save())'
- [aopc] was broken for method call:CarDAO.save()V calls Driver.method()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] WARNING: declare-warning condition
- [aopc] 'class($instanceof{VehicleDAO}) AND !has(public void *->save())'
- [aopc] was broken for class MotorbikeDAO
- [aopc] All VehicleDAO subclasses must override the save() method.
-
-run:
- [java] ---- Start ----
- [java] Car DAO save
-
-BUILD SUCCESSFUL
-}}}
-
-Note that when using compile time instrumentation the warnings are generated during the aopc phase.
-
-!Run the example load-time instrumented
-
-{{{
- $ ant run.50.instrumented
-}}}
-
-{{{
-run.50.instrumented:
- [java] ---- Start ----
- [java] WARNING: declare-warning condition
- [java] 'call(Driver->new(..)) AND within(*DAO)'
- [java] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [java] DAO classes should not access the Driver class
-
- [java] WARNING: declare-warning condition
- [java] 'call(* Driver->*(..)) AND withincode(* *DAO->save())'
- [java] was broken for method call:CarDAO.save()V calls Driver.method()V
- [java] DAO classes should not access the Driver class
-
- [java] Car DAO save
- [java] WARNING: declare-warning condition
- [java] 'class($instanceof{VehicleDAO}) AND !has(public void *->save())'
- [java] was broken for class MotorbikeDAO
- [java] All VehicleDAO subclasses must override the save() method.
-
-
-
-
-BUILD SUCCESSFUL
-}}}
-Note that now the warnings are displayed when running the application, as the classes are transformed when loaded.
-
-!!Declaring errors
-If we replace all the {{@DeclareWarning}} occurances with {{@DeclareError}} in {{DeclareAspect}}, an error will get thrown instead
-{{{
-import org.jboss.aop.DeclareError;
-
- at Aspect
-public class DeclareAspect
-{
- @DeclareError (expr="class($instanceof{VehicleDAO}) AND !has(public void *->save())", msg="All VehicleDAO subclasses must override the save() method.")
- Pointcut warning1;
-
- @DeclareError (expr="call(Driver->new(..)) AND within(*DAO)", msg="DAO classes should not access the Driver class")
- Pointcut warning2;
-
- @DeclareError (expr="call(* Driver->*(..)) AND withincode(* *DAO->save())", msg="DAO classes should not access the Driver class")
- Pointcut warning3;
-
-}
-}}}
-
-!!declare-error precompiled
-When running precompiled we get:
-{{{
-$ ant
-Buildfile: build.xml
-
-prepare:
-
-compile:
- [javac] Compiling 5 source files to C:\cygwin\home\Kab\cvs\jboss-head\aop\docs\examples\annotated-declare
- [aopc] ERROR: declare-error condition
- [aopc] 'call(Driver->new(..)) AND within(*DAO)'
- [aopc] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] java.lang.RuntimeException: ERROR: declare-error condition
- [aopc] 'call(Driver->new(..)) AND within(*DAO)'
- [aopc] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] at org.jboss.aop.instrument.DeclareChecker.checkDeclares(DeclareChecker.java:124)
- [aopc] at org.jboss.aop.instrument.DeclareChecker.checkDeclares(DeclareChecker.java:57)
- [aopc] at org.jboss.aop.instrument.CallerTransformer$CallerExprEditor.edit(CallerTransformer.java:472)
- [aopc] at javassist.expr.ExprEditor.doit(ExprEditor.java:136)
- [aopc] at javassist.CtBehavior.instrument(CtBehavior.java:362)
- [aopc] at org.jboss.aop.instrument.CallerTransformer.applyCallerPointcuts(CallerTransformer.java:69)
- [aopc] at org.jboss.aop.instrument.Instrumentor.applyCallerPointcuts(Instrumentor.java:495)
- [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:562)
- [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.java:564)
- [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.java:482)
- [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compiler.java:251)
- [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:184)
- [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:67)
- [aopc] [error] failed to transform: CarDAO.. Do verbose mode if you want full stack trace.
- [aopc] Exception in thread "main" java.lang.RuntimeException: failed to transform: CarDAO
- [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:615)
- [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.java:564)
- [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.java:482)
- [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compiler.java:251)
- [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:184)
- [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:67)
- [aopc] Caused by: javassist.CannotCompileException: by java.lang.RuntimeException: ERROR: declare-error condition
- [aopc] 'call(Driver->new(..)) AND within(*DAO)'
- [aopc] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] at org.jboss.aop.instrument.CallerTransformer$CallerExprEditor.edit(CallerTransformer.java:501)
- [aopc] at javassist.expr.ExprEditor.doit(ExprEditor.java:136)
- [aopc] at javassist.CtBehavior.instrument(CtBehavior.java:362)
- [aopc] at org.jboss.aop.instrument.CallerTransformer.applyCallerPointcuts(CallerTransformer.java:69)
- [aopc] at org.jboss.aop.instrument.Instrumentor.applyCallerPointcuts(Instrumentor.java:495)
- [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:562)
- [aopc] ... 5 more
-
-}}}
-
-See how the compiler stops at the first error and execution stops.
-
-!!DeclareError loadtime
-When running with loadtime transformations we get:
-{{{
-$ ant run.50.instrumented
-Buildfile: build.xml
-
-prepare:
-
-compile50standalone:
- [javac] Compiling 5 source files to C:\cygwin\home\Kab\cvs\jboss-head\aop\docs\examples\annotated-declare
-
-run.50.instrumented:
- [java] ---- Start ----
- [java] ERROR: declare-error condition
- [java] 'call(Driver->new(..)) AND within(*DAO)'
- [java] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [java] DAO classes should not access the Driver class
-
- [java] java.lang.RuntimeException: ERROR: declare-error condition
- [java] 'call(Driver->new(..)) AND within(*DAO)'
- [java] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [java] DAO classes should not access the Driver class
-
- [java] at org.jboss.aop.instrument.DeclareChecker.checkDeclares(DeclareChecker.java:124)
- [java] at org.jboss.aop.instrument.DeclareChecker.checkDeclares(DeclareChecker.java:57)
- [java] at org.jboss.aop.instrument.CallerTransformer$CallerExprEditor.edit(CallerTransformer.java:472)
- [java] at javassist.expr.ExprEditor.doit(ExprEditor.java:136)
- [java] at javassist.CtBehavior.instrument(CtBehavior.java:362)
- [java] at org.jboss.aop.instrument.CallerTransformer.applyCallerPointcuts(CallerTransformer.java:69)
- [java] at org.jboss.aop.instrument.Instrumentor.applyCallerPointcuts(Instrumentor.java:495)
- [java] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:562)
- [java] at org.jboss.aop.AspectManager.translate(AspectManager.java:564)
- [java] at org.jboss.aop.AspectManager.transform(AspectManager.java:482)
- [java] at org.jboss.aop.standalone.AOPTransformer.transform(AOPTransformer.java:28)
- [java] at sun.instrument.TransformerManager.transform(TransformerManager.java:122)
- [java] at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
- [java] at java.lang.ClassLoader.defineClass1(Native Method)
- [java] at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
- [java] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
- [java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
- [java] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
- [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
- [java] at java.security.AccessController.doPrivileged(Native Method)
- [java] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
- [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
- [java] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
- [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
- [java] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
- [java] at Driver.createVehicles(Driver.java:24)
- [java] at Driver.main(Driver.java:19)
- [java] [error] failed to transform: CarDAO.. Do verbose mode if you want full stack trace.
- [java] Car DAO save
- [java] [error] failed to transform: MotorbikeDAO.. Do verbose mode if you want full stack trace.
-
-}}}
-Again you can see how the first broken condition causes execution to stop.
Deleted: projects/aop/trunk/aop/docs/examples/annotated-dynamic-cflow/annotated-dynamic-cflow.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-dynamic-cflow/annotated-dynamic-cflow.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-dynamic-cflow/annotated-dynamic-cflow.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,54 +0,0 @@
-!!!Annotated Dynamic Control Flow
-
-!Overview
-Dynamic CFlows work similar to when defined in [XML|../dynamic_cflow/cflow.html]. The only difference is how to declare it using annotations.
-
-!Implement DynamicCFlow
-Take a look at {{SimpleDynamicCFlow}}:
-{{{
-import org.jboss.aop.joinpoint.Invocation;
-import org.jboss.aop.pointcut.DynamicCFlow;
-import org.jboss.aop.DynamicCFlowDef;
-
- at DynamicCFlowDef
-public class SimpleDynamicCFlow implements DynamicCFlow
-{
- public static boolean runit = false;
-
- public boolean shouldExecute(Invocation invocation)
- {
- return runit;
- }
-}
-}}}
-
-This is exactly the same as in the [XML|../dynamic_cflow/cflow.html] example. The only difference is that we declare the dynamic cflow class by annotating it with @DynamicCFlowDef.
-
-!Use in bindings
-You use the dynamic cflow in bindings exactly the same way as you would do with any other cflow (apart from this time we use the fully qualified name of the {{@DynamicCFlowDef}} annotated class). Here is the relevant bit of SimpleInterceptor:
-{{{
- @InterceptorDef
- @Bind (pointcut="execution(void POJO->method1())", cflow="SimpleDynamicCFlow")
- public class SimpleInterceptor implements Interceptor
- {
- ...
- }
-}}}
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo.method4(); ---
- [java] method1
- [java] --- turn on cflow ---
- [java] <<< Entering SimpleInterceptor for: public void POJO.method1()
- [java] method1
- [java] >>> Leaving SimpleInterceptor
-
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-injboss/annotated-injboss.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-injboss/annotated-injboss.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-injboss/annotated-injboss.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,64 +0,0 @@
-!!! Running and packaging in JBoss
-
-This example is exactly the same as the [XML|../injboss/aopInJbossPackaging.html] example. Please see that for a description of the application, and how the different examples are built up. The differences are outlined below
-
-__To run these examples you must edit build.xml and set the jboss.dir to where JBoss is. The server configuration used in this example is 'all', so you must start JBoss with 'run -c all'. __
-
-!! JDK 1.5
-JDK 1.5 must be used for this example, this involves:
-*deleting JBOSS_HOME/server/all/jboss-aop.deployer
-*copying jboss-40-install/jboss-aop-jdk50.deployer from the AOP distribution into the JBOSS_HOME/server/all/ folder
-*using JDK 5.0 when you run JBoss
-*building the example with JDK 1.5
-
-!!Interceptors and bindings
-Instead of defining out interceptors and bindings via XML, they are defined via annotations in the {{SimpleInterceptor}} class. (For the long @Bind annotation newlines have been added to the pointcut string for readability)
-
-{{{
- at InterceptorDef
- at Bind (pointcut="org.jboss.injbossaop.lib.SimpleInterceptor.valueConstructors OR
- org.jboss.injbossaop.lib.SimpleInterceptor.valueMessage OR
- org.jboss.injbossaop.lib.SimpleInterceptor.service OR
- org.jboss.injbossaop.lib.SimpleInterceptor.sessionValue OR
- org.jboss.injbossaop.lib.SimpleInterceptor.mbeans")
-public class SimpleInterceptor implements Interceptor
-{
- @PointcutDef ("execution(org.jboss.injbossaop.lib.ExampleValue->new(..))")
- public static Pointcut valueConstructors;
-
- @PointcutDef ("execution(* org.jboss.injbossaop.lib.ExampleValue->getMessage())")
- public static Pointcut valueMessage;
-
- @TypeDef ("class($instanceof{javax.servlet.http.HttpServlet}) AND class(org.jboss.injbossaop.web.*)")
- public static Typedef servlets;
-
- @PointcutDef ("execution(* $typedef{org.jboss.injbossaop.lib.SimpleInterceptor.servlets}->service(..))")
- public static Pointcut service;
-
- @TypeDef ("class($instanceof{javax.ejb.SessionBean}) AND class(org.jboss.injbossaop.ejb.*)")
- public static Typedef sessionBeans;
-
- @PointcutDef ("execution(* $typedef{org.jboss.injbossaop.lib.SimpleInterceptor.sessionBeans}->getValue(..))")
- public static Pointcut sessionValue;
-
- @PointcutDef ("all(org.jboss.injbossaop.mbean.*)")
- public static Pointcut mbeans;
-
- public String getName() { return "SimpleInterceptor"; }
-
- ...
-}
-
-}}}
-
-
-!!Bye bye XML
-For JBoss AOP to look for annotations in a deployed application, it must be packaged in a {{.aop}} file, so the only configurations from the original [XML|../injboss/aopInJbossPackaging.html] example that work for annotations are:
-*deploy-basic-lt-war-in-sar
-*deploy-ear-aop
-*deploy-example-lt-sar
-
-Please see the original example for details of how these are packaged. The other configurations in the original example did not use {{.aop}} files, and they had a standalone XML file containing the bind info, which is not what we are demonstrating in this example.
-
-One quirk of the {{.aop}} format is that the file must contain a {{META-INF/jboss-aop.xml}} file in order to be valid. So this file is used for the examples, although it is empty and so contains no binding information.
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-interceptors/annotated-interceptors.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-interceptors/annotated-interceptors.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-interceptors/annotated-interceptors.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,71 +0,0 @@
-!!!Annotated interceptors
-
-!!Declaring interceptor class
-You declare an interceptor in exactly the same way as defined in [Method execution|../method-execution/methodexecution.html]. i.e. the interceptor must inherit from {{org.jboss.aop.advice}}
-{{{
-package org.jboss.aop.advice;
-
-import org.jboss.aop.joinpoint.Invocation;
-
-public interface Interceptor
-{
- public String getName();
- public Object invoke(Invocation invocation) throws Throwable;
-}
-}}}
-
-!!Binding the interceptor
-Open up {{SimpleInterceptor}}, and you will see that the class itself is normal, but that the class has been annotated as follows:
-{{{
- import org.jboss.aop.Bind;
- import org.jboss.aop.InterceptorDef;
-
- @InterceptorDef
- @Bind (pointcut = "all(POJO)")
- public class SimpleInterceptor implements Interceptor
- {
- ...
- }
-}}}
-
-The {{@InterceptorDef}} marks the class as an interceptor so that JBoss AOP knows what to do with it. The @Bind annotation specifies the pointcut the interceptor should be bound to. So in this case {{SimpleInterceptor}} gets bound to all constructor executions, method calls and field accesses on the POJO class. This example uses an [all|../all/all.html] pointcut expression, but you can of course use any pointcut expression you like. {{SimpleInterceptor.java}} contains a few commented out example bindings so you can get rid of and introduce the ones you want. (Note that there can be only one uncommented @Bind at any time)
-
-!! build.xml
-An important difference between defining the AOP bindings as annotations rather than xml, is that you don't have a jboss-aop.xml file. Instead you need to tell the aopc compiler and the java runtime where to find the annotated files by using the aopclasspath property (for the aopc task) or the jboss.aop.class.path system property (for the java runtime) as shown below:
-{{{
- ...
- <aopc compilerclasspathref="classpath" classpathref="classpath" verbose="true">
- <classpath path="."/>
- <src path="."/>
- <aopclasspath path="."/>
- </aopc>
-
- ...
-
- <java fork="yes" failOnError="true" className="Driver">
- <sysproperty key="jboss.aop.class.path" value="."/>
- <classpath refid="classpath"/>
- </java>
- ...
-}}}
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] <<< Entering SimpleInterceptor for: public POJO()
- [java] constructor
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.noop(); ---
- [java] <<< Entering SimpleInterceptor for: public void POJO.noop()
- [java] noop()
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.test1(String param); ---
- [java] <<< Entering SimpleInterceptor for: public void POJO.test1(java.lang.String)
- [java] test1(String param): hello world
- [java] >>> Leaving SimpleInterceptor
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-introduction/annotated-introduction.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-introduction/annotated-introduction.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-introduction/annotated-introduction.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,82 +0,0 @@
-!!!Introductions
-
-!Overview
-The principles behind introductions and mixins when using annotations are exactly the same as when using [XML|introductions/introductions.html], all that is different is the way you define it.
-
-!Introductions
-
-You declare the introductions within a class that has been annotated with {{@Aspect}} or {{@InterceptorDef}}. {{MyAspect}} in this example serves no purpose beyond allowing you to define introductions (i.e. it contains no actual advices).
-
-{{{
- import org.jboss.aop.Introduction;
-
- @Aspect
- public class MyAspect
- {
- @Introduction (target=POJO.class, interfaces={java.io.Serializable.class})
- public static Object noInterfacesPOJOIntro;
-
- ...
- }
-
-}}}
-
-Basically, you just annotate any field within the aspect with {{@Introduction}}. The {{target}} attribute takes the class you want to introduce interfaces into, and the {{interfaces}} attribute takes an array of the interfaces you want to add to the class.
-
-
-
-!Mixins
-You declare the mixins in much the same way as you declare introductions. Again, it must be done within a class that has been annotated with {{@Aspect}} or {{@InterceptorDef}}.
-{{{
- import org.jboss.aop.Mixin;
-
- @Aspect
- public class MyAspect
- {
- ...
-
- @Mixin (target=POJO2.class, interfaces={java.io.Externalizable.class})
- public static POJO2ExternalizableMixin createExternalizableMixin(POJO2 pojo) {
- return new POJO2ExternalizableMixin(pojo);
- }
- }
-}}}
-You annotate a public static method within the aspect with {{@Mixin}}. The {{target}} attribute takes the class you want to introduce interfaces into, and the {{interfaces}} attribute takes an array of the interfaces you want to add to the class. The method must take a class of the same type as the target as its parameter, and it must contain the logic to create and return an instance of the mixin class.
-
-!Type expressions
-The {{target}} attribute for {{@Introduction}} and {{@Mixin}} takes a fixed class. You can use the {{typeExpression}} attribute in place of {{target}} to make the {{@Introduction}} or {{@Mixin}} apply to a wider range of classes.
-{{{
- import org.jboss.aop.Mixin;
-
- @Aspect
- public class MyAspect
- {
- ...
-
- @Introduction (typeExpression="class(POJO3) OR class(POJO4)", interfaces={java.io.Serializable.class})
- public static Object withTypeExpression;
- }
-}}}
-
-
-!Running the example
-
-{{{
-$ ant
-}}}
-
-The output should be:
-
-{{{
-run:
- [java] --- POJO ---
- [java] deserialized pojo.stuff: hello world
- [java] --- POJO2 ---
- [java] deserialized pojo2.stuff2: hello world
- [java] --- POJO3 ---
- [java] pojo3 introduction expression worked
- [java] --- POJO4 ---
- [java] pojo4 introduction expression worked
-}}}
-
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-parameters/annotated-parameters.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-parameters/annotated-parameters.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-parameters/annotated-parameters.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,319 +0,0 @@
-!!!Annotated Advice Parameters
-
-!Overview
-In generated advisor (default) mode, before, after and around advices can receive
-annotated parameters. The use of annotations provides maximum flexibility to the
-signature of advices, since an advice can receive only the values that are relevant
-to its execution. These parameters can be in any order and their type can be the type
-that is the most suitable to the advice functionality, according to the joinpoints it
-intercepts.
-
-!Annotated Parameter Signature
-
-The annotated parameter signature is defined as:
-
-{{{
-public <return-value> <any-method-name>(@<Annotation> <any type> arg0, @<Annotation> <any type> arg1, ... , @<Annotation> <any type> argN) throws <Exception1>,<Exception2>,...,<ExceptionN>
-}}}
-
-This signature is available for all kinds of advices in JBoss AOP (when running in
-the generated advisor instrumentation mode). Besides this one, JBoss AOP supports the
-default around signature, introduced in the [Aspect example|../aspect/aspect.html"].
-The default signature can only be used to write around advices, and is supported on
-all instrumentation modes.
-
-Basicaly, this signature allows an advice to receive zero or more annotated
-parameters, in any order, and with any valid type. Regarding the exception types, an
-advice is allowed to declare any exception in its signature. {{RuntimeException}}s
-are rethrown by JBoss AOP as is. The same goes for exceptions
-that are not runtime, if they are declared in the joinpoint exceptions list (
-supposing the joinpoint has an exception list). Otherwise, the exception will be
-wrapped in a {{RuntimeException}}. In all cases, the application would get the
-exception as if the joinpoint itself had thrown it.
-
-A concrete example of this signature has been shown in the [before/after|../beforeafter/beforeafter.html] example:
-
-{{{
-public void beforeAdvice(@JoinPoint Joinpoint joinPoint)
-}}}
-
-As we can see, this advice receives one parameter annotated with
-{{@JoinPoint}}.
-
-Next, we will see all parameter annotations that can be used by an advice. Notice
-that an empty parameter list is also valid, as in the following signatures:
-
-{{{
-public void beforeNoParameters()
-
-public Object aroundNoParameters() throws Throwable
-
-public void afterNoParameters()
-}}}
-
-
-!Parameter Annotations
-
-JBoss AOP demands the use of parameter annotations to identify advice parameters.
-These parameters can represent several values, like the joinpoint target, a joinpoint
-argument, or its return value. In this example, we show all parameter annotations
-that can be used by before, after and around advices. These annotations are located
-in the {{org.jboss.aop.advice.annotation}} package.
-
-The type of an annotated parameter can be chosen accordingly to the value it refers
-to. For example, suppose you are intercepting a jointpoint with an argument of type
-{{ArrayList<String>}}. Advices that refer to this argument as being of type
-{{ArrayList<String>}}, or {{Collection<String>}} or {{Object}} would all be
-considered correct. This is useful because you can access specific operations and
-fields of the argument, without performing a cast, and yet you can receive a super
-type like {{Object}} and refer to arguments of different types when your advice is
-applied to different joinpoints.
-
-Notice that, as a convention, we named the advices of this example after the names of
-parameter annotations. Besides, all advices names are prefixed with their types names
-(before advice names start with {{"before"}}, and so on). It is also important
-to point out that, as all previous examples, the name of advices can be chosen freely
-and JBoss AOP won't use these names to identify annotated parameters.
-
-__ at JoinPoint__
-
-This annotation is used on objects that represent a joinpoint. If the advice
-is an around advice, the type of this object belongs to the
-[Invocation class hierarchy|../../misc/invocation.html]. On all other
-advices, joinpoints are represented by types of the
-[JoinPoint interface hierarchy|../../misc/joinpoint.html], as follows:
-
-{{{
-public void beforeJoinPoint(@JoinPoint JoinPointInfo joinPointInfo)
-
-public Object aroundJoinPoint(@JoinPoint CallerInvocation invocation) throws Throwable
-
-public void afterJoinPoint(@JoinPoint ConstructorInfo joinPointInfo)
-}}}
-
-Notice how {{beforeJoinPoint}} advice receives a parameter of the supertype
-{{JoinPointInfo}} while, in {{afterJoinPoint}}, the parameter is of the more
-specific type {{ConstructorInfo}}, valid only on constructor execution
-joinpoints.
-To see these and all other advice examples, open up the {{Aspect.java}} file.
-
-__ at Target__
-
-This annotation is used on parameters that refer to the joinpoint target. The
-joinpoint target is defined according to the joinpoint type. For example, the target
-of a method execution is the object whose method is being executed. On a call
-joinpoint, the target is the object whose method is being called. On a field access
-joinpoint, the target is the object that contains the field. Notice that not all
-joinpoints have a target. Static method executions and calls, static field reads
-and writes, and constructor executions and calls don't have a target.
-
-Examples of usage of this annotation follow:
-
-{{{
-public void beforeTarget(@Target Object target)
-
-public Object aroundTarget(@Target POJO target) throws Throwable
-
-public void afterTarget(@Target POJO target) throws Throwable
-}}}
-
-By opening up {{jboss-aop.xml}}, you can see that the target of all these
-advices is of type {{POJO}}, yet {{beforeTarget}} advice receives a target
-of type {{Object}}. Since {{POJO}} extends {{Object}}, this is
-perfectly valid, and useful when an advice intercepts joinpoints with different
-target types.
-
-__ at Caller__
-
-This annotation is used on parameters that refer to the caller object, during a call
-joinpoint interception. This should be used only on call joinpoints. If the call is
-inside a static method, the caller will be {{null}}.
-Examples follow:
-
-{{{
-public void beforeCaller(@Caller POJO caller)
-
-public Object aroundCaller(@Caller Driver target) throws Throwable
-
-public void afterCaller(@Caller Object target)
-}}}
-
-__ at Return__
-
-Use this annotation only on after advices, to refer to the joinpoint return value:
-
-{{{
-public void afterFieldReturn(@Return Object joinPointReturn)
-
-public void afterMethodReturn(@Return boolean joinPointReturn)
-}}}
-
-__ at Arg__
-
-This annotation is used to refer to a joinpoint argument. Since a joinpoint can
-receive more than one argument, this is the only annotation that can be used on more
-than one advice parameters.
-Look at these examples:
-
-{{{
-public void beforeConstructorArg(@Arg Object argument)
-
-public Object aroundConstructorArg(@Arg String argument) throws Throwable
-
-public void afterArg(@Arg int argument)
-}}}
-
-When the joinpoint receives multiple arguments, JBoss AOP infers to which
-argument an {{@Arg}} annotated parameter refers. In this example, both
-{{beforeConstructorArg}} and {{aroundConstructorArg}} are applied to
-{{POJO}} constructor, whose unique argument is of type {{java.lang.String}}.
-So, the parameters of these advices will refer to this constructor argument.
-On the other hand, {{afterArg}} advice is applied to more than one method
-executions:
-
-{{{
-public class POJO
-{
- ...
-
- public boolean someMethod(int argument)
- {
- ...
- }
-
- public void method(long arg0, int arg1, long arg2, String arg3)
- {
- ...
- }
-
- ...
-}
-}}}
-
-Wen intercepting {{POJO.someMethod(int)}} execution, the parameter of {{afterArg}}
-will contain the value of the single argument {{someMethod}} received, as it happens
-with {{beforeConstructorArg}} and {{aroundConstructorArg}} advices. But, when
-intercepting {{POJO.method(long,int,long,String)}}, JBoss AOP will automatically
-associate {{afterArg}} parameter with the parameter at index position {{1}}, of type
-{{int}}.
-
-Associating the {{int}} value is easy, because there is only one joinpoint
-argument of that type. The same doesn't apply to the following advice:
-
-{{{
-public void beforeMethodArg(@Arg long argument)
-}}}
-
-Given that {{POJO->method(long,int,long,String)}} has two arguments of type {{long}},
-JBoss AOP will pick the first {{long}} typed argument. If you want to refer to the
-second {{long}} typed argument, in position {{2}}, you can use the optional
-{{@Arg.index}} element as is shown below:
-
-{{{
-public void beforeMethodArg2(@Arg(index=2) long argument)
-}}}
-This element can be set everytime JBoss AOP does not associate your {{@Arg}}
-annotated parameter with the joinpoint argument you want to receive.
-
-__ at Arguments__
-
-Finally, this annotation is used on advice parameters of type <tt>java.lang.Object TODO ARRAY </tt>, that contain the complete list of the joinpoint arguments.
-
-Look at these examples:
-
-{{{
-public void beforeArgs(@Args Object[] arguments)
-
-public Object aroundArgs(@Args Object[] arguments) throws Throwable
-
-public void afterArgs(@Args Object[] arguments)
-}}}
-
-Use this annotation when you need a generic advice, that receives all arguments
-without knowing how many arguments there are, or their types. Using {{@Arguments
-}} instead of a list of {{@Arg}} annotated parameters is useful when you need to
-change one or more joinpoint argument values. An example is the {{beforeArgs}} advice,
-that ovewrites two argument values of {{POJO.method(long,int,long,String)}} execution:
-
-{{{
-public void beforeArgs(@Args Object[] arguments)
-{
- ...
- arguments[3] = "overridenString";
- arguments[1] = Integer.valueOf(((Integer)arguments[1]).intValue() - 50);
- ...
-}
-}}}
-
-Avoid using {{@Arguments}} when none of those conditions apply. This
-parameter type can incur in the creation of an array and of wrapper objects (as is
-the case of argument 1 above). Besides, you have the extra cost of downcasting
-the arguments.
-<h4>Run the example</h4>
-
-__THIS EXAMPLE REQUIRES JDK 1.5!!__ To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
-
- [java] Calling POJO constructor
- [java] ========================
- [java] >>> beforeConstructorArg: Object "Driver"
- [java] >>> aroundConstructorArg: String "Driver"
- [java] RUNNING new POJO("Driver")
- [java] >>> afterJoinPoint: ConstructorInfo Constructor[constructor=public POJO(java.lang.String)]
-
- [java] Setting POJO->field with "text" value
- [java] =======================================
- [java] >>> beforeJoinPoint: FieldInfo Field Write[field=public java.lang.Object POJO.field]
- [java] >>> aroundTarget: POJO POJO at 19209ea
- [java] >>> aroundArgs: arguments [text]
-
- [java] Reading POJO->field value
- [java] =========================
- [java] >>> aroundArgs: arguments null
- [java] >>> aroundNoParameters
- [java] >>> afterFieldReturn: Object text
- [java] >>> afterNoParameters
-
- [java] Calling POJO->method(int)
- [java] =========================
- [java] >>> aroundArgs: arguments [17]
- [java] RUNNING POJO->method(17)
- [java] >>> afterArg: int 17
- [java] >>> afterArgs: arguments [17]
-
- [java] Calling POJO->method(long, int, long, String)
- [java] =============================================
- [java] >>> beforeMethodArg: long 20L
- [java] >>> beforeMethodArg2: long 1000L
- [java] >>> beforeArgs changing arguments: from [20, 2, 1000, Driver]
- [java] to [20, -48, 1000, overridenString]
- [java] >>> aroundArgs: arguments [20, -48, 1000, overridenString]
- [java] RUNNING POJO->method(20L, -48, 1000L, "overridenString")
- [java] >>> afterArg: int -48
- [java] >>> afterArgs: arguments [20, -48, 1000, overridenString]
-
- [java] Calling POJO->someMethod(int)
- [java] =============================
- [java] >>> beforeNoParameters
- [java] RUNNING POJO->someMethod()
- [java] >>> afterMethodReturn: boolean true
- [java] >>> afterArg: int 10
-
- [java] Calling POJO->callMethod()
- [java] ==========================
- [java] >>> aroundCaller: Driver null
- [java] >>> aroundArgs: arguments []
- [java] RUNNING POJO->callMethod()
- [java] >>> beforeTarget: Object POJO at 19209ea
- [java] >>> beforeCaller: POJO POJO at 19209ea
- [java] >>> aroundJoinPoint: CallerInvocation JoinPoint_MByM__N_6287195452448676113POJO_N_1153034853916900765_8 at f99ff5
- [java] RUNNING POJO->calledMethod()
- [java] >>> afterTarget: POJO POJO at 19209ea
- [java] >>> afterCaller: Object POJO at 19209ea
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-precedence/annotated-precedence.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-precedence/annotated-precedence.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-precedence/annotated-precedence.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,100 +0,0 @@
-!!!Annotated Interceptor Precedence
-
-!Background
-The theory for precedence is the same as in the [XML|../precedence/precedence.html] example, but when using annotations precedence is declared differently. Also, the whole concept of precedence is somewhat more important when applied to an application where the AOP bindings are defined using annotations rather than in XML, since using XML the interceptions occur in the order they have been defined, while using annotations there is no other notion of ordering of interceptions.
-
-!!Defining
-
-You define precedence in a separate class annotated with @Precedence
-{{{
- import org.jboss.aop.Precedence;
- import org.jboss.aop.PrecedenceInterceptor;
-
- @Precedence
- public class Precedence1
- {
-
- @PrecedenceInterceptor
- public static SimpleInterceptor precedenceInterceptor1;
-
- @PrecedenceInterceptor
- public static SimpleInterceptor2 precedenceInterceptor2;
- }
-}}}
-
-The @PrecedenceInterceptor is used to annotate fields where the type is an interceptor, and the orderings within the class define the relative sort order for the precedence. In other words this class defines that
-{{{
- SimpleInterceptor
- comes before
- SimpleInterceptor2
-}}}
-
-{{Precedence2}} also defines a set of precedences:
-{{{
- @Precedence
- public class Precedence2
- {
- @PrecedenceInterceptor
- public static SimpleInterceptor2 simple2;
-
- @PrecedenceAdvice ("advice")
- public static TestAspect advice;
-
- @PrecedenceInterceptor
- public static SimpleInterceptor3 simple3;
-
- @PrecedenceAdvice ("otherAdvice")
- public static TestAspect otherAdvice;
- }
-}}}
-
-The @PredenceAdvice is used to annotate fields where the type is an aspect. The attribute value in the @PrecedenceAdvice annotation is the name of the advice method in the aspect, so:
-{{{
- SimpleInterceptor2
- comes before
- TestAspect.advice
- comes before
- SimpleInterceptor3
- comes before
- TestAspect.otherAdvice
-}}}
-
-The precedence entries are merged into an
-overall precedence entry, so that:
-
-{{{
- SimpleInterceptor
- comes before
- SimpleInterceptor2
- comes before
- TestAspect.advice
- comes before
- SimpleInterceptor3
- comes before
- TestAspect.otherAdvice
-}}}
-
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] <<< Entering SimpleInterceptor type: POJO0OptimizedConstructorInvocation
- [java] <<< Entering SimpleInterceptor2 type: POJO0OptimizedConstructorInvocation
- [java] <<< Entering TestAspect.advice type:POJO0OptimizedConstructorInvocation at f6a746
- [java] <<< Entering SimpleInterceptor3 type: POJO0OptimizedConstructorInvocation
- [java] <<< Entering TestAspect.otherAdvice type:POJO0OptimizedConstructorInvocation at f6a746
- [java] empty constructor
- [java] <<< Leaving TestAspect.otherAdvice type:POJO0OptimizedConstructorInvocation at f6a746
- [java] >>> Leaving SimpleInterceptor3
- [java] <<< Leaving TestAspect.advice type:POJO0OptimizedConstructorInvocation at f6a746
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
-}}}
-
-
Deleted: projects/aop/trunk/aop/docs/examples/annotated-typedef/annotated-typedef.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotated-typedef/annotated-typedef.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotated-typedef/annotated-typedef.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,87 +0,0 @@
-!!! Annotated Typedefs
-
-The theory about how typedefs work is the same as when defining them via [XML|typedef/typedef.html]. This example shows you how to define them using annotations
-
-Let's take a look at SimpleInterceptor.java
-
-{{{
-import org.jboss.aop.TypeDef;
-import org.jboss.aop.pointcut.Typedef;
-
- at InterceptorDef
- at Bind (pointcut = "all($typedef{SimpleInterceptor.myTypedef})")
-public class SimpleInterceptor implements Interceptor
-{
- @TypeDef ("(class(POJO) AND has(* *->method(..))) OR class($instanceof{ExecutionTypedefInterface})")
- public static Typedef myTypedef;
-
- public String getName() { return "SimpleInterceptor"; }
-
- public Object invoke(Invocation invocation) throws Throwable
- {
- ...
- }
-}
-}}}
-
-{{SimpleInterceptor}} contains a field annotated with {{@TypeDef}}, which specifies a type expression for all classes to be used for the typedef. As for the [Annotated composition|../annotated-composition/annotated-composition.html] example, the fully qualified name of the field itself is used as the name when we want to reference the typedef. We have used a field type of {{Typedef}} for clarity, but the actual type of the field is irrelevant.
-
-{{SimpleInterceptor}} and {{SimpleInterceptor2}} both reference the typedef in their {{@Bind}} annotation:
-{{{
- @Bind (pointcut = "all($typedef{SimpleInterceptor.myTypedef})")
-}}}
-
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.field1 = 10; ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- get pojo.field1;---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.method(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
-
- [java] =======================
-
- [java] --- new POJO2(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo2.field1 = 10; ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- get pojo2.field1; ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo2.method(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotation/annotation.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotation/annotation.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotation/annotation.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,78 +0,0 @@
-!!!Annotations for JDK 1.5
-
-!Overview
-JDK 1.5 has a new interesting feature called annotations. It allows you to specify xdoclet like tags right in the Java language just as you can with C#. These tags are typesafe and access to them is available at compile time, load-time, and run-time. See [JSR-175|http://www.jcp.org/en/jsr/detail?id=175] for more detail. JBossAOP since beta2 does support JDK1.5 annotations
-
-A good way to visualize metadata is to think of classnames, method names, field names, and constructor signatures as nouns, and annotations/metadata as adjectives. You can declare advice/interceptor bindings like: All @Remotable objects should register with a dispatcher whenever they are constructed. Any method marked @transactional begin/commit/rollback a transaction at the start and end of the method. Or even any field, method, constructor marked @traceable, do tracing. It kinda lets the application developer give hints to the aspect developer. If you think about it another way, combining annotations and AOP allows you to plug in new Java keywords. Kinda like C pre-processor macros on steroids. Macros that are typesafe and checked by the compiler and unlike Major League Baseball players, it will always be legal for you to use these steroids in your applications.
-
-!Example code
-The example code applies 2 separate interceptors via tags supplied in a Java source file. One of the interceptors is a tracing interceptor that is trigger by a @trace annotation, the other is B2B functionality that will bill/charge a user for each access of the api. This is also triggered by an annotation.
-
-!Declaring annotations
-Open up POJO.java. This is the source file for where our annotations will be declared.
-
-{{{
- @trace @billable
- public void someMethod()
- {
- System.out.println("someMethod");
- }
-}}}
-In the above example, we are declaring someMethod() to be traced and billable. Don't forget! At least with JDK 1.5 beta, you must compile your Java source files with 1.5 source to have annotations compile.
-{{{
-$ javac -source 1.5 MyFile.java
-}}}
-
-
-!Annotations in pointcut expressions
-Annotations can be referenced by an '@' sign in pointcut expressions. They can only be used in the class expressions for a method, field, or constructor for execution and caller pointcuts. They can also be used in substitute for 'new' in constructor land, and for a method or field name. Take a look at jboss-aop.xml
-
-{{{
- <bind pointcut="execution(POJO->@billable(..))">
- <interceptor class="BillingInterceptor"/>
- </bind>
-
- <bind pointcut="execution(* POJO->@billable(..))">
- <interceptor class="BillingInterceptor"/>
- </bind>
-
-}}}
-
-The first binding above says that for every constructor tagged as @billable apply the BillingInterceptor. The second binding states that for any method tagged as @billable apply the BillingInterceptor. Let's now take a look at applying the tracing advice.
-
-{{{
- <bind pointcut="all(@trace)">
- <interceptor class="TraceInterceptor"/>
- </bind>
-}}}
-
-The above states that for any field, constructor, or method tagged as @trace, apply the TraceInterceptor.
-
-!Running
-__THIS EXAMPLE REQUIRES JDK 1.5!!__ To compile and run:
-{{{
- $ ant
-}}}
-This should be the output:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] populateMixinMethods*****
- [java] billing...org.jboss.aop.joinpoint.ConstructorInvocation at 1ee4648
- [java] <<< Trace : executing constructor public POJO()
- [java] empty constructor
- [java] >>> Leaving Trace
- [java] --- new POJO(int); ---
- [java] <<< Trace : executing constructor public POJO(int)
- [java] int constructor
- [java] >>> Leaving Trace
- [java] --- pojo.someMethod(); ---
- [java] billing...org.jboss.aop.joinpoint.MethodInvocation at 1b383e9
- [java] <<< Trace : executing method public void POJO.someMethod()
- [java] someMethod
- [java] >>> Leaving Trace
- [java] --- pojo.field = 55; ---
- [java] <<< Trace : write field name: public int POJO.field
- [java] >>> Leaving Trace
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotation-introductions/annotation.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotation-introductions/annotation.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotation-introductions/annotation.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,45 +0,0 @@
-!!!Annotation Introductions
-
-!Overview
-This is an extension of the annotation14 example. In this example, instead of declaring an annotation within the Java source file, we ''introduce'' an annotation through an XML descriptor. This XML descriptor has the same effect as declaring an annotation the JDK 1.5 way, or the JDK 1.4 way.
-
-!Example code
-The example code declares annotations via doclets within POJO.java. single.java, trace.java, and complex.java all represent our annotation interfaces. The TraceInterceptor traces method, field, and constructor calls on POJO and outputs the annotations tagged on those members;
-
-!Applying an Annotation Introduction
-
-jboss-aop.xml
-{{{
- <annotation-introduction expr="constructor(POJO->new())">
- @complex (ch='a', string="hello world", flt=5.5, dbl=6.6, shrt=5, lng=6, integer=7, bool=true, annotation=@single("hello"), array={"hello", "world"}, clazz=java.lang.String)
- </annotation-introduction>
-}}}
-
-It is pretty simple, define an expression within the ''expr'' attribute. ''constructor()'', ''method()'', ''class()'', and ''field()'' all take a corresponding expression of that type. You can also use the ''has()'' and ''hasfield()'' operators as well if you wish and any boolean expression with those 6 operators.
-
-!Running
-{{{
- $ ant
-}}}
-This should be the output:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] @single ("hello world")
- [java] @complex (ch='a', "hello world", flt=5.5, dbl=6.6, ...blah blah blah YOU GET THE IDEA...
- [java] <<< Trace : executing constructor public POJO()
- [java] empty constructor
- [java] >>> Leaving Trace
- [java] --- pojo.someMethod(); ---
- [java] @single ("hello world")
- [java] @complex (ch='a', "hello world", flt=5.5, dbl=6.6, ...blah blah blah YOU GET THE IDEA...
- [java] <<< Trace : executing method public void POJO.someMethod()
- [java] someMethod
- [java] >>> Leaving Trace
- [java] --- pojo.field = 55; ---
- [java] @single ("hello world")
- [java] @complex (ch='a', "hello world", flt=5.5, dbl=6.6, ...blah blah blah YOU GET THE IDEA...
- [java] <<< Trace : write field name: public int POJO.field
- [java] >>> Leaving Trace
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/annotation14/annotation.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/annotation14/annotation.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/annotation14/annotation.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,109 +0,0 @@
-!!!JDK 1.5 Annotations with JDK 1.4
-
-!Overview
-JDK 1.5 has a new interesting feature called annotations. It allows you to specify xdoclet like tags right in the Java language just as you can with C#. These tags are typesafe and access to them is available at compile time, load-time, and run-time. See [JSR-175|http://www.jcp.org/en/jsr/detail?id=175] for more detail. JBossAOP since beta2 does support JDK1.5 annotations
-
-A good way to visualize metadata is to think of classnames, method names, field names, and constructor signatures as nouns, and annotations/metadata as adjectives. You can declare advice/interceptor bindings like: All @Remotable objects should register with a dispatcher whenever they are constructed. Any method marked @transactional begin/commit/rollback a transaction at the start and end of the method. Or even any field, method, constructor marked @traceable, do tracing. It kinda lets the application developer give hints to the aspect developer. If you think about it another way, combining annotations and AOP allows you to plug in new Java keywords. Kinda like C pre-processor macros on steroids. Macros that are typesafe and checked by the compiler and unlike Major League Baseball players, it will always be legal for you to use these steroids in your applications.
-
-So, what good are JDK 1.5 annotations if you're using a JDK 1.4 compiler???? Well, JBoss AOP has an annotation compiler for JDK 1.4 that can convert typed annotations from doclet tags and embed them in your class files. This bytecode manipulation is compatible with JDK 1.5.
-
-!Example code
-The example code declares annotations via doclets within POJO.java. single.java, trace.java, and complex.java all represent our annotation interfaces. The TraceInterceptor traces method, field, and constructor calls on POJO and outputs the annotations tagged on those members;
-
-!Implementing annotations
-Open up complex.java. You'll see that it is a regular interface. This is our annotation implementation and is the same as JDK 1.5 except ''@interface'' is replaced with a plain interface.
-
-complex.java
-{{{
-public interface complex
-{
- char ch();
- String string();
- float flt();
- double dbl();
- short shrt();
- long lng();
- int integer();
- boolean bool();
- single annotation();
- String[] array();
- Class clazz();
-}
-}}}
-
-!Declaring annotations
-Open up POJO.java. This is the source file for where our annotations will be declared. The syntax is exactly the same as JDK 1.5 annotations except that they are embedded as doclet tags and you use a double at sign '@@'.
-__IMPORTANT NOTE__ You must have a space after the tag name otherwise you will get a compilation error. This is the quirkiness of the QDox doclet compiler.
-
-{{{
- /**
- * @@trace
- * @@single ("hello world")
- * @@complex (ch='a', string="hello world", flt=5.5, dbl=6.6, shrt=5, lng=6, integer=7, bool=true, annotation=@single("hello"), array={"hello", "world"}, clazz=java.lang.String)
- */
- public void someMethod()
- {
- System.out.println("someMethod");
- }
-}}}
-
-!Compiling annotations
-All class files must be compiled before the annotation compiler runs. All files must also be available in the annotation compiler's classpath. Look at build.xml. It shows how to run the annotation compiler as an ANT task.
-
-{{{
- <annotationc compilerclasspathref="classpath" classpathref="classpath" bytecode="true">
- <src path="."/>
- </annotationc>
-}}}
-
-For the annotation compiler to run, it has two requires:
-# Java source files must be available in path specified by the <src> tag
-# All Java source files must have been previously compiled and available in the the ''classpath''. Any annotated source files must have their corresponding .class files available for manipulation within a file-system based classpath (i.e. NOT within a jar).
-
-The bytecode manipulations done to annotated classes are compatible with JDK 1.5. So, if you rewrite your JDk 1.4 annotations interfaces (changing the keyword interface to @interface), the annotated classes can be used with both JDK 1.4 and 1.5. I was going to ship an implementation of java.lang.annotation.Annotation and force JDK 1.4 annotation interfaces to implement this (and thus be fully binary compatible), but the Java license forbids you to distribute anything under the java.lang package. :( Oh well.
-
-
-!Annotations in pointcut expressions
-Annotations can be referenced by an '@' sign in pointcut expressions. They can only be used in the class expressions for a method, field, or constructor for execution and caller pointcuts. They can also be used in substitute for 'new' in constructor land, and for a method or field name. Take a look at jboss-aop.xml
-
-{{{
- <bind pointcut="all(@trace)">
- <interceptor class="TraceInterceptor"/>
- </bind>
-}}}
-
-The above states that for any field, constructor, or method tagged as @trace, apply the TraceInterceptor.
-
-!Accessing annotations at runtime
-The org.jboss.aop.annotation.AnnotationElement is an abstraction to obtain annotations at runtime. It works with both JDK 1.4 and JDK 1.5 so you can write portable code. The TraceInterceptor shows how to access annotations.
-
-{{{
- complex c = (complex)AnnotationElement.getAnyAnnotation(((MethodInvocation)invocation).getMethod(), complex.class);
-}}}
-
-!Running
-{{{
- $ ant
-}}}
-This should be the output:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] @single ("hello world")
- [java] @complex (ch='a', "hello world", flt=5.5, dbl=6.6, ...blah blah blah YOU GET THE IDEA...
- [java] <<< Trace : executing constructor public POJO()
- [java] empty constructor
- [java] >>> Leaving Trace
- [java] --- pojo.someMethod(); ---
- [java] @single ("hello world")
- [java] @complex (ch='a', "hello world", flt=5.5, dbl=6.6, ...blah blah blah YOU GET THE IDEA...
- [java] <<< Trace : executing method public void POJO.someMethod()
- [java] someMethod
- [java] >>> Leaving Trace
- [java] --- pojo.field = 55; ---
- [java] @single ("hello world")
- [java] @complex (ch='a', "hello world", flt=5.5, dbl=6.6, ...blah blah blah YOU GET THE IDEA...
- [java] <<< Trace : write field name: public int POJO.field
- [java] >>> Leaving Trace
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/aspect/aspect.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/aspect/aspect.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/aspect/aspect.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,100 +0,0 @@
-!!!Aspects and Around Advices
-
-!Overview
-The Interceptor classes shown in previous examples are a little limiting in that you can only have one advice per class. JBossAOP allows you to group advices into one Java class. This is what JBossAOP calls an Aspect. An Aspect is a collection of advices expressed as methods.
-
-!Writing an aspect
-An aspect class is a plain Java class. It does not have to inherit from anything, but it must have an empty constructor.
-JBoss AOP supports several types of advices. In this example, we will introduce the around advice and its default signature.
-Each around advice can follow this format:
-
-{{{
- public Object <any-method-name>(<any Invocation type>) Throwable
-}}}
-
-You can also overload methods.
-
-!Scope and XML definitions
-You can specify the scope of an aspect's instance. By Scope, I mean whether the aspect is allocated once per JVM, once per Class it is tied to, or once per Instance. You must declare an aspect definition in XML. The Scope is optional and defaults to once per JVM. Open up jboss-aop.xml to see declarations of aspects.
-
-{{{
- <aspect class="AspectPerVM" scope="PER_VM"/>
- <aspect class="AspectPerClass" scope="PER_CLASS"/>
- <aspect class="AspectPerInstance" scope="PER_INSTANCE"/>
-}}}
-
-There are three aspect classes. They all count field, method and constructor accesses from within themselves.
-
-You bind specific advices by referencing the method names within advice bindings. jboss-aop.xml again gives examples of this
-
-{{{
- <bind pointcut="execution(POJO*->new())">
- <advice name="constructorAdvice" aspect="AspectPerVM"/>
- <advice name="constructorAdvice" aspect="AspectPerClass"/>
- </bind>
-}}}
-
-The above binding states that whenever a POJO or POJO2's constructor get's invoked call the method constructorAdvice on the AspectPerVM class and the method constructorAdvice on the AspectPerClass object. Remember, because of the scope defined, AspectPerVM will be allocated once for the entire VM. Any bindings that reference advices within that aspect class will share the same AspectPerVM instance. There is one AspectPerClass instance per class it is bound to. So there is an AspectPerClass instance for POJO and POJO2.
-
-{{{
- <bind pointcut="execution(void POJO*->someMethod())">
- <advice name="methodAdvice" aspect="AspectPerVM"/>
- <advice name="methodAdvice" aspect="AspectPerClass"/>
- <advice name="methodAdvice" aspect="AspectPerInstance"/>
- </bind>
-
- <bind pointcut="field(* POJO*->field)">
- <advice name="fieldAdvice" aspect="AspectPerVM"/>
- <advice name="fieldAdvice" aspect="AspectPerClass"/>
- <advice name="fieldAdvice" aspect="AspectPerInstance"/>
- </bind>
-}}}
-
-The final two bindings intercept field and method access of POJO and POJO2.
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] ---- POJO ---
- [java] AspectPerVM.constructorAdvice accessing: public POJO()
- [java] AspectPerClass.constructorAdvice accessing: public POJO()
- [java] empty constructor
- [java] AspectPerVM.fieldAdvice reading field: field
- [java] AspectPerClass.fieldAdvice reading field: field
- [java] AspectPerInstance.fieldAdvice reading field: field
- [java] AspectPerVM.fieldAdvice writing to field: field
- [java] AspectPerClass.fieldAdvice writing to field: field
- [java] AspectPerInstance.fieldAdvice writing to field: field
- [java] AspectPerVM.methodAdvice accessing: public void POJO.someMethod()
- [java] AspectPerClass.methodAdvice accessing: public void POJO.someMethod()
- [java] AspectPerInstance.methodAdvice accessing: public void POJO.someMethod()
- [java] someMethod
- [java] ---- POJO2 ---
- [java] AspectPerVM.constructorAdvice accessing: public POJO2()
- [java] AspectPerClass.constructorAdvice accessing: public POJO2()
- [java] POJO2 empty constructor
- [java] AspectPerVM.fieldAdvice reading field: field
- [java] AspectPerClass.fieldAdvice reading field: field
- [java] AspectPerInstance.fieldAdvice reading field: field
- [java] AspectPerVM.fieldAdvice writing to field: field
- [java] AspectPerClass.fieldAdvice writing to field: field
- [java] AspectPerInstance.fieldAdvice writing to field: field
- [java] AspectPerVM.methodAdvice accessing: public void POJO2.someMethod()
- [java] AspectPerClass.methodAdvice accessing: public void POJO2.someMethod()
- [java] AspectPerInstance.methodAdvice accessing: public void POJO2.someMethod()
- [java] POJO2 someMethod
- [java] -- get stats --
- [java] perVM stats: 2 2 2 2
- [java] POJO perClass stats: 1 1 1 1
- [java] POJO2 perClass stats: 1 1 1 1
- [java] pojo perInstance stats: 1 1 1
- [java] pojo2 perInstance stats: 1 1 1
-}}}
-
-
-
Deleted: projects/aop/trunk/aop/docs/examples/beanstyleconf/config.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/beanstyleconf/config.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/beanstyleconf/config.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,217 +0,0 @@
-!!!JavaBean-Style Configuration of Aspects/Interceptors
-
-!!Passing in attributes
-You can configure aspects/interceptors by passing in parameters when you define them. The attribute child element is used to pass in the values.
-{{{
- <aop>
- <interceptor class="ConfigInterceptor" scope="PER_CLASS">
- <attribute name="Attr1">aa</attribute>
- <attribute name="Attr2">1</attribute>
- </interceptor>
-
- <aspect class="ConfigAspectPerVm" scope="PER_VM">
- <attribute name="Attr">aspect,per,vm</attribute>
- </aspect>
-
- <aspect class="ConfigAspectPerClass" scope="PER_CLASS">
- <attribute name="Attr">aspect,per,class</attribute>
- </aspect>
-
- <aspect class="ConfigAspectPerInstance" scope="PER_INSTANCE">
- <attribute name="Attr">aspect,per,instance</attribute>
- </aspect>
-
- <aspect class="ConfigAspectPerJoinpoint" scope="PER_JOINPOINT">
- <attribute name="Attr">aspect,per,joinpoint</attribute>
- </aspect>
-
- ...
- <aop>
-}}}
-
-The name attribute is used to indicate which property you want to set, and the contents of the attribute is the value. Valid types are all the primitives (String, float, int etc.), or an array of Strings. The aspect/interceptor must contain a setter matching the signature implied by the configuration in jboss-aop.xml. In this example we have:
-
-{{{
- public class ConfigInterceptor implements Interceptor
- {
- String attr1;
- int attr2;
- ...
-
- public void setAttr1(String s)
- {
- attr1 = s;
- System.out.println("setAttr1: " + s);
- }
-
- public void setAttr2(int i)
- {
- attr2 = i;
- System.out.println("setAttr2: " + i);
- }
- ...
- }
-
- public class ConfigAspectPerVm
- {
- String[] attr1;
-
- ...
- public void setAttr(String[] attr1)
- {
- this.attr1 = attr1;
- }
- }
-}}}
-
-
-So, in the bindings above, JBoss AOP will call ConfigInterceptor.setAttr1("aa"), ConfigInterceptor.setAttr2(1), ConfigAspectPerVm.setAttr({"aspect", "per", "vm"}). ConfigAspectPerClass, ConfigAspectPerInstance and ConfigAspectPerJoinpoint are more or less the same as ConfigAspectPerVm.
-
-
-!!Injection of AOP constructs
-A similar scheme to what is outlined above is used for injecting information about the Advisor, InstanceAdvisor and Joinpoint for the intereceptor. The definition of SimpleInterceptor is shown here, but is exactly the same for ConfigAspectPerVm, ConfigAspectPerClass, ConfigAspectPerInstance and ConfigAspectPerJoinpoint aspects.
-
-{{{
-<aop>
- <interceptor class="ConfigInterceptor" scope="PER_CLASS">
-
- ...
- <advisor-attribute name="MyAdvisor"/>
- <instance-advisor-attribute name="MyInstanceAdvisor"/>
- <joinpoint-attribute name="MyJoinpoint"/>
- </interceptor>
-
-<aop>
-}}}
-
-For injecting the Advisor, the setMyAdvisor() method will be called.
-For injecting the InstanceAdvisor, the setMyInstanceAdvisor() method will be called.
-For injecting the Joinpoint, the setMyJoinpoint() method will be called.
-
-The setters used by ConfigInterceptor are shown here:
-
-{{{
- public class ConfigInterceptor implements Interceptor
- {
- ...
- Advisor advisor;
- InstanceAdvisor instanceAdvisor;
- Joinpoint jp;
-
- ...
- public void setMyAdvisor(Advisor advisor)
- {
- this.advisor = advisor;
- }
-
- public void setMyInstanceAdvisor(InstanceAdvisor instanceAdvisor)
- {
- this.instanceAdvisor = instanceAdvisor;
- }
-
- public void setMyJoinpoint(Joinpoint jp)
- {
- this.jp = jp;
- }
- }
-
-}}}
-
-
-!!Scoping and Injection of AOP constructs
-Whether an Advisor, InstanceAdvisor or Joinpoint exists for an aspect/interceptor depends on the scope. The following table shows what can be injected for the different scopes.
-
-{{{
-
- Scope\AOP construct Advisor InstanceAdvisor Joinpoint
-
- PER_VM no no no
- PER_CLASS yes no no
- PER_INSTANCE yes*) yes*) no
- PER_JOINPOINT yes yes*) yes
-
-}}}
-
-(The ones marked with *) are not available when invoking a static method or reading/writing a static field.)
-
-
-
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] setAttr1: aa
- [java] setAttr2: 1
- [java] WARN: Ignoring attempt to set instance advisor attribute on aspect/i
-nterceptor: ConfigInterceptor which is not scoped PER_INSTANCE or PER_JOINPOINT
- [java] WARN: Ignoring attempt to set joinpoint attribute on aspect/intercep
-tor: ConfigInterceptor which is not scoped PER_JOINPOINT
- [java] setAttr1: aa
- [java] setAttr2: 1
- [java] WARN: Ignoring attempt to set instance advisor attribute on aspect/i
-nterceptor: ConfigInterceptor which is not scoped PER_INSTANCE or PER_JOINPOINT
- [java] WARN: Ignoring attempt to set joinpoint attribute on aspect/intercep
-tor: ConfigInterceptor which is not scoped PER_JOINPOINT
- [java] WARN: Ignoring attempt to set advisor attribute on PER_VM scoped asp
-ect/interceptor: ConfigAspectPerVm
- [java] WARN: Ignoring attempt to set instance advisor attribute on aspect/i
-nterceptor: ConfigAspectPerVm which is not scoped PER_INSTANCE or PER_JOINPOINT
- [java] WARN: Ignoring attempt to set joinpoint attribute on aspect/intercep
-tor: ConfigAspectPerVm which is not scoped PER_JOINPOINT
- [java] WARN: Ignoring attempt to set instance advisor attribute on aspect/i
-nterceptor: ConfigAspectPerClass which is not scoped PER_INSTANCE or PER_JOINPOI
-NT
- [java] WARN: Ignoring attempt to set joinpoint attribute on aspect/intercep
-tor: ConfigAspectPerClass which is not scoped PER_JOINPOINT
- [java] POJO empty constructor
- [java] --- pojo.interceptorMethod(); ---
- [java] <<< Entering ConfigInterceptor type: ConfigInterceptor at 17ee8b8
- [java] attr1:aa; attr2:1
- [java] has advisor: true
- [java] has instanceAdvisor: false
- [java] has joinpoint: false
- [java] POJO interceptorMethod
- [java] >>> Leaving ConfigInterceptor
- [java] --- pojo.aspectPerVmMethod(); ---
- [java] >>> Enter ConfigAspectPerVm
- [java] attr1: index 0=aspect, index 1=per, index 2=vm
- [java] has advisor: false
- [java] has instanceAdvisor: false
- [java] has joinpoint: false
- [java] POJO aspectPerVmMethod
- [java] >>> Leave ConfigAspectPerVm
- [java] --- pojo.aspectPerClassMethod(); ---
- [java] <<< Enter ConfigAspectPerClass
- [java] attr1: index 0=aspect, index 1=per, index 2=class
- [java] has advisor: true
- [java] has instanceAdvisor: false
- [java] has joinpoint: false
- [java] POJO aspectPerClassMethod
- [java] >>> Leave ConfigAspectPerClass
- [java] --- pojo.aspectPerInstanceMethod(); ---
- [java] WARN: Ignoring attempt to set joinpoint attribute on aspect/intercep
-tor: ConfigAspectPerInstance which is not scoped PER_JOINPOINT
- [java] <<< Enter ConfigAspectPerInstance
- [java] attr1: index 0=aspect, index 1=per, index 2=instance
- [java] has advisor: true
- [java] has instanceAdvisor: true
- [java] has joinpoint: false
- [java] POJO aspectPerInstanceMethod
- [java] >>> Leave ConfigAspectPerInstance
- [java] --- pojo.aspectPerJoinpointMethod(); ---
- [java] <<< Enter ConfigAspectPerJoinpoint
- [java] attr1: index 0=aspect, index 1=per, index 2=joinpoint
- [java] has advisor: true
- [java] has instanceAdvisor: true
- [java] has joinpoint: true
- [java] POJO interceptorMethod
- [java] >>> Leave ConfigAspectPerJoinpoint
-
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/beforeafter/beforeafter.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/beforeafter/beforeafter.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/beforeafter/beforeafter.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,342 +0,0 @@
-!!!Before and After Advices
-
-!!Overview
-JBoss AOP provides several types of advices. The advices seen on the previous
-section, as well as JBoss AOP interceptors, provide around join point interception.
-In this example we introduce before and after advices, and compare their roles to
-around advices' role.
-
-!!Writing Before/After Advices
-
-Before and after advices are lightweight advices when compared to around advices.
-JBoss AOP invokes these advices before or after the joinpoint execution.
-
-As we will see in the next [example|../annotated-parameters/annotated-parameters.html],
-these advices can have several different signatures. However, in our
-first example, we will use signatures that are closest to what has been shown on
-previous examples.
-
-So, we introduce a before and after advices as being of the form:
-
-{{{
-public void <any-method-name>(@JoinPoint <any Joinpoint type>)
-}}}
-
-Differently from around advices and interceptors, throwing a {{Throwable}} is
-not necessary, because these advices do not wrap a joinpoint.
-
-Instead of {{Invocation}} instances, before/after advices receive instances
-of [{{org.jboss.aop.IJoinpointInfo}} and subinterfaces|../../misc/joinpoint.html]
-as parameters.
-
-Furthermore, one can notice the presence of the parameter annotation {{@org.jboss.aop.advice.annotation.JoinPoint}}. This is necessary because
-before/after advices can receive values with several semantic roles as parameters.
-As we will see [next|../annotated-parameters/annotated-parameters.html],
-this annotation is used to distinguish this parameter type from the other ones, so we
-can achieve flexibility on the type, order and presence of advice parameters.
-
-!!Binding Before/After Advices
-
-To bind a before/after advice to a pointcut, you only need to declare an xml binding as
-follows (open up {{jboss-aop.xml}} to see this example):
-
-{{{
-<bind pointcut="execution(public void $instanceof{Transaction}->run())">
- <before name="beforeAdvice" aspect="mypackage.MutexAspect"/>
- <after name="afterAdvice" aspect="mypackage.MutexAspect"/>
-</bind>
-}}}
-
-As you can see, you just need to declare a usual bind tag, and add to it
-{{<before>}} and {{<after>}} tags for before and after advices
-respectively. We can also mix interceptor declarations and around, before, and
-after advices declarations in a single binding.
-
-
-!!Around, Before and After Advices
-
-As seen on previous sections, around advices wrap the joinpoint execution. An around
-advice replaces the joinpoint execution in the base system, and is responsible for
-forwarding execution to the joinpoint itself, as well as for returning a value to the
-base system.
-
-Around advices can be composed by four parts at most: a before joinpoint execution
-block, a proceed to joinpoint step, an after joinpoint execution block, and, finally,
-a return value step. To see an example, consider this {{PER_VM}} scoped aspect:
-
-{{{
-public class SynchronizationAspect
-{
- public Object aroundAdvice(Invocation invocation) throws Throwable
- {
- Object result;
-
- // part 1: retrive lock before joinpoint execution
- synchronized(this)
- {
- System.out.println(">>> Retrieved concurrency lock");
-
- // part 2: proceed to joinpoint execution
- result = invocation.invokeNext();
-
- // part 3: release lock after joinpoint execution
- System.out.println("<<< Releasing concurrency lock");
- }
-
- // part 4: return result
- return result;
- }
-}
-}}}
-
-{{SynchronizationAspect}} synchronizes all intercepted joinpoints (in a
-concurrent programming application), avoiding that two or more intercepted joinpoints
-run at the same time.
-
-As we can see, {{SynchronizationAspect.aroundAdvice()}} is composed of four
-steps:
-
-* retrieving a lock before the joinpoint execution, achieved by entering the {{synchronized}} block;
-* proceeding to joinpoint execution;
-* releasing the lock after the joinpoint execution, achieved by exiting the {{synchronized}} block;
-* and returning the joinpoint result.
-
-Notice that this advice does not alter joinpoint execution (the advice does not
-skip it) nor its return result (the advice could overwrite this value, but returns
-the joinpoint return value itself instead). Hence, we can say that the relevant part
-of it is only what is performed before and after the joinpoint (parts 1 and 3). To
-illustrate the before/after concept, we wish to replace this single around advice
-by a couple of before/after advices. However, we cannot do that by using the
-previous example. A synchronized block cannot be splitten into two parts and still
-achieve the same effect. So, lets first replace this around advice by one that uses a
-mutex intead of a synchronized block:
-
-{{{
-public class MutexAspect
-{
- private Object lock = new Object();
- private boolean locked = false;
-
- public Object aroundAdvice(Invocation invocation) throws Throwable
- {
- Object result;
-
- // part 1: retrive lock before joinpoint execution
- synchronized(lock)
- {
- while (locked)
- {
- try
- {
- lock.wait();
- }
- catch(InterruptedException e)
- {
- Thread.currentThread().interrupt();
- return;
- }
- }
- locked = true;
- System.out.println(">>> Retrieved concurrency lock");
- }
-
- // part 2: proceed to joinpoint execution
- result = invocation.invokeNext();
-
- // part 3: release lock after joinpoint execution
- synchronized(lock)
- {
- locked = false;
- lock.notify();
- System.out.println("<<< Releasing concurrency lock");
- }
-
- // part 4: return result
- return result;
- }
-}
-}}}
-
-As much as {{SynchronizedAspect}}, {{MutexAspect}} avoids simultaneous
-access to the intercepted joinpoint, and is also composed of the four steps
-(getting a lock, proceeding to joinpoint execution and releasing the lock).
-
-Now we can easily split this around advice into two advices: one that retrieves
-the lock, and another one that releases it. We wish to run the first one before a
-joinpoint, and the other one, after it.
-
-The example that follows is a copy of the previous one, except that, now, {{MutexAspect.aroundAdvice()}} has been splitten into {{MutexAspect.beforeAdvice()
-}} and {{MutexAspect.afterAdvice()}}:
-
-{{{
-public class MutexAspect
-{
- private Object lock = new Object();
- private boolean locked = false;
-
- public void beforeAdvice(@JoinPoint Joinpoint joinPoint)
- {
- synchronized(lock)
- {
- while (locked)
- {
- try
- {
- lock.wait();
- }
- catch(InterruptedException e)
- {
- Thread.currentThread().interrupt();
- return;
- }
- }
- locked = true;
- System.out.println(">>> Retrieved concurrency lock");
- }
- }
-
- public void afterAdvice(@JoinPoint Joinpoint joinPoint)
- {
- synchronized(lock)
- {
- locked = false;
- lock.notify();
- System.out.println("<<< Releasing concurrency lock");
- }
- }
-}
-}}}
-
-Notice that, in this version, parts 2 and 4 are gone (proceeding to joinpoint
-execution and returning its result). This is due to the fact that before and after
-advices don't wrap a joinpoint, they are just executed before or after it.
-
-!!Around vs Before/After
-
-As is shown in this example, around advices can generally be broken into two related
-before and after advices. The reverse is also true.
-However, there are some subtleties that can help you to choose one form or the
-other.
-
-First of all, these are features that are available only to around advices:
-
-* capability of replacing the entire joinpoint execution, by skipping the call to {{Invocation.invokeNext() method}};
-* capability of skipping the invocation of subsequent around advices and interceptors, by calling {{Invocation.invokeTarget()}} instead of {{Invocation.invokeNext()}};
-* addition of meta-data, available on Invocation objects only.
-
-When you need one of those advanced features, you should use an around advice or
-interceptor. Besides, there are aspects that cannot be implemented as a
-pair of before and after advices. An example would be the {{SynchronizedAspect}}
-shown before. A synchronized block cannot be broken into two blocks and achieve the
-same result as one single synchronized block. In the example, we wrote a similar,
-more complex aspect to illustrate the before/after advice concept. In real
-applications, however, this aspect would not be replaced by a more complex one,
-unless this could bring advantages to the application.
-
-On the other hand, before and after advices also provide some advantages. A pair of
-related before/after advices:
-
-* is lightweight, when compared to around advices
-* can be bound to different joinpoints. The before advice can be invoked before joinpoint A and the after advice, after joinPoint B
-
-Since they are more lighweight, prefer using a pair of before/after advices, unless
-you have a reason to do otherwise.
-Regarding the second item in the list, it can be extremely useful in the case of
-MutexAspect. Instead of controling the multi-threaded access to a single joinpoint,
-we could obtain the lock before a joinpoint, and release it later, after a different
-joinpoint execution. This allows the synchronization of a sequence of joinpoints as
-if they were a single unit.
-
-Lets remark that replacing the joinpoint return value is not a feature exclusive to around
-advices and interceptors. An after advice can also return a value (for more on this,
-refer to the [Return Types|../return-types/return-types.html] example).
-
-!!Unrelated Before and After Advices
-
-Despite the application of before and after advices shown in this example, these
-advices can also be used in an unrelated, independent manner.
-
-An aspect whose code needs to run only before the joinpoint execution should contain
-only before advices. The same applies to an aspect that needs to execute after
-a joinpoint execution, regarding after advices. Furthermore, an aspect that provides
-functionalities that need to be run before a joinpoint execution, and functionalities
-that need to be run after, should contain a mix of unrelated before and after advices.
-
-Examples of unrelated before and after advices will be shown in the next examples of
-this tutorial.
-
-!!Applying MutexAspect
-
-In our example, we apply {{MutexAspect}} to a classic example of synchronization
-and concurrent programming application.
-
-Suppose you have bank accounts and operations on accounts can be performed
-concurrently. If we don't synchronize those operations we can end up with an invalid
-account balance.
-
-An example would be two operations on account {{A}}. Suppose one of them
-is a deposit of $30.00, while the other one is a withdrawal of $10.00. If these
-operations are run in an unsynchronized manner, like follows:
-
-* deposit: read balance: $50.00
-* withdrawal: read balance: $50.00
-* deposit: add $30.00
-* withdrawal: subtract $10.00
-* deposit: write final balance of $80.00
-* withdrawal: write final balance of $40.00
-
-The final balance of the account would be $40.00, and the deposit of $50.00 would
-have been completely ignored, since its final balance has been overwritten by
-the withdrawal operation.
-
-!!Running
-
-__THIS EXAMPLE REQUIRES JDK 1.5!!__ To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should be similar to this:
-{{{
-run:
- [java] SETUP
- [java] =====
- [java] Creating account 'A' with initial balance of $30.0
- [java] Creating account 'B' with initial balance of $50.0
- [java] Creating account 'C' with initial balance of $0.0
-
- [java] TRANSACTIONS
- [java] ============
- [java] Using context classloader sun.misc.Launcher$AppClassLoader at 133056f to load aspect mypackage.MutexAspect
- [java] Using context classloader sun.misc.Launcher$AppClassLoader at 133056f to load aspect mypackage.MutexAspect
- [java] >>> Retrieved concurrency lock
- [java] Depositing US$ 50.00 to account A
- [java] <<< Releasing concurrency lock
- [java] >>> Retrieved concurrency lock
- [java] Transfering US$ 100.00 from account B to account C
- [java] <<< Releasing concurrency lock
- [java] >>> Retrieved concurrency lock
- [java] Withdrawing US$ 10.00 from account A
- [java] <<< Releasing concurrency lock
- [java] >>> Retrieved concurrency lock
- [java] Transfering US$ 89.11 from account C to account A
- [java] <<< Releasing concurrency lock
- [java] >>> Retrieved concurrency lock
- [java] Depositing US$ 51.00 to account B
- [java] <<< Releasing concurrency lock
- [java] >>> Retrieved concurrency lock
- [java] Withdrawing US$ 0.11 from account C
- [java] <<< Releasing concurrency lock
- [java] >>> Retrieved concurrency lock
- [java] Withdrawing US$ 5.00 from account B
- [java] <<< Releasing concurrency lock
-
- [java] FINAL BALANCE
- [java] ===== =======
- [java] A: US$ 159.11
- [java] C: US$ 10.78
- [java] B: -US$ 4.00
-
-}}}
-
-You can add accounts and transactions to this example application by editing the
-{{input.txt}} file.
Deleted: projects/aop/trunk/aop/docs/examples/caller/caller.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/caller/caller.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/caller/caller.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,52 +0,0 @@
-!!!Caller pointcuts
-
-!Callers
-Execution pointcuts on methods and constructors are very useful, but limiting some times. For instance, what if you don't want a method to be intercepted once you are within the method's class? Another problem is that JBoss AOP does not allow you to have an execution pointcut applied to any Java system classes. This is where caller pointcuts come in. Executions are invoked whenever the method is called within the method itself. Callers are invoked at the point of the calling code. Callers allow you to specify what method in what class calls whatever method. Confused? Here's some examples from jboss-aop.xml.
-{{{
- <bind pointcut="call(int java.util.ArrayList->size()) AND withincode(void Driver->caller())">
- <interceptor class="CallerInterceptor1"/>
- </bind>
-}}}
-Whenever {{ArrayList.size()}} method is called from within the {{Driver.caller()}} method, invoke {{CallerInterceptor1}}. You see? You can specify the point of interception from within the caller's code. You can also use boolean expressions to specify your within:
-{{{
- <bind pointcut="call(int java.util.ArrayList->size()) AND withincode(* Driver->*(..)) AND !withincode(void Driver->caller())">
- <interceptor class="CallerInterceptor2"/>
- </bind>
-}}}
-This binding states to invoke {{CallerInterceptor2}} whenever {{ArrayList.size()}} is called from within any {{Driver}} class method, but not from within {{Driver.caller()}}.
-
-{{{
- <bind pointcut="call(java.util.ArrayList->new()) AND within(Driver)">
- <interceptor class="CallerInterceptor1"/>
- </bind>
-}}}
-This binding is a little different in that it uses the within keyword rather than the withincode keyword. Within matches anything within an entire class. So the above pointcut states, whenever the ArrayList empty constructor is called from within any method or constructor of the Driver class.
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- main is calling new ArrayList(); ---
- [java] <<< Entering CallerInterceptor1
- [java] >>> Leaving CallerInterceptor1
- [java] --- main is calling list.size(); ---
- [java] <<< Entering CallerInterceptor2
- [java] >>> Leaving CallerInterceptor2
- [java] --- caller is calling new ArrayList(); ---
- [java] <<< Entering CallerInterceptor1
- [java] >>> Leaving CallerInterceptor1
- [java] --- caller is calling list.size(); ---
- [java] <<< Entering CallerInterceptor1
- [java] >>> Leaving CallerInterceptor1
- [java] --- anotherCaller is calling new ArrayList(); ---
- [java] <<< Entering CallerInterceptor1
- [java] >>> Leaving CallerInterceptor1
- [java] --- anotherCaller is calling list.size(); ---
- [java] <<< Entering CallerInterceptor2
- [java] >>> Leaving CallerInterceptor2
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/cflow/cflow.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/cflow/cflow.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/cflow/cflow.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,87 +0,0 @@
-!!!Control Flow
-
-!Overview
-Control flow is a runtime construct. It allows you to specify pointcut parameters revolving around the call stack of a Java program. You can do stuff like, if method A calls method B calls Method C calls Method D from Constructor A, trigger this advice. The best thing to do is look at an example. Cflow's are quite expensive in JBoss AOP as they parse Throwable.getStackTrace to determine if the advice should be triggered at runtime.
-
-!CFlow Stack
-A {{<cflow-stack>}} element is used to define method and/or constructor you want to watch for in a call stack. It is top down, where the first declared element in a {{<cflow-stack>}} is the top of the Java call stack. Each {{<called>}} element expresses either a method or constructor. This declaration will try to eat part of the call stack starting from the top. If it successfully matches a member in the stack, then next {{<called>}} element will be matched from the point in the stack the last call matched. {{<not-called}} elements do not eat the stack. Let's look at the example declarations within jboss-aop.xml
-
-{{{
- <cflow-stack name="ShowOnlyWhen123Before">
- <called expr="void POJO->method1()"/>
- <called expr="void POJO->method2()"/>
- <called expr="void POJO->method3()"/>
- </cflow-stack>
-}}}
-
-This first cflow-stack declares that method1, method2, and method3 should be in the call stack in that order. The next
-{{{
- <cflow-stack name="ShowOnlyWhenConstructorAnd3">
- <called expr="POJO->new(int)"/>
- <called expr="void POJO->method3()"/>
- </cflow-stack>
-}}}
-Says that the POJO constructor with an int parameter and method3 must be in the call stack in that order
-
-!Apply a cflow-stack
-cflow-stacks can only be applied to a binding. They can be compositional as well. Let's take a look at the example in jboss-aop.xml.
-
-{{{
- <bind pointcut="execution(void POJO->method4())" cflow="(ShowOnlyWhen123Before OR ShowOnlyWhenConstructorAnd3)">
- <interceptor class="SimpleInterceptor"/>
- </bind>
-}}}
-This says to trigger the SimpleInterceptor on the execution of method4, but only when it is called within the context of method1, method2, and method3 OR contructor and method3. When you run the driver you will see this in action. Look at how Driver.java invokes on POJO methods, then example the output of the program.
-
-The next example is for recursive methods. The example cflow-stack says that two calls to the recursive method must be in the call stack, but no more
-{{{
- <cflow-stack name="showSecondRecursiveCall">
- <called expr="void POJO->recursive(int)"/>
- <called expr="void POJO->recursive(int)"/>
- <not-called expr="void POJO->recursive(int)"/>
- </cflow-stack>
-
- <bind pointcut="execution(void POJO->recursive(int))" cflow="showSecondRecursiveCall">
- <interceptor class="SimpleInterceptor"/>
- </bind>
-
-}}}
-
-Combined with the execution binding, the SimpleInterceptor will only be triggered on the second call to the recursive method.
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo.method4(); ---
- [java] method4
- [java] --- pojo.method3(); ---
- [java] method3
- [java] method4
- [java] --- pojo.method2(); ---
- [java] method2
- [java] method3
- [java] method4
- [java] --- pojo.method1(); ---
- [java] method1
- [java] method2
- [java] method3
- [java] <<< Entering SimpleInterceptor for: public void POJO.method4()
- [java] method4
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.recursive(); ---
- [java] recursive: 1
- [java] <<< Entering SimpleInterceptor for: public void POJO.recursive(int)
- [java] recursive: 2
- [java] recursive: 3
- [java] >>> Leaving SimpleInterceptor
- [java] --- new POJO(int); ---
- [java] method3
- [java] <<< Entering SimpleInterceptor for: public void POJO.method4()
- [java] method4
- [java] >>> Leaving SimpleInterceptor
-}}}
Deleted: projects/aop/trunk/aop/docs/examples/composition/composition.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/composition/composition.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/composition/composition.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,50 +0,0 @@
-!!!Compositional and Named Pointcuts
-
-JBossAOP pointcuts are fully compositional. You can have multiple exeuction, field, and call expressions joined together by boolean operators (AND, OR, !) in one big expression. You also do not have to always tie a pointcut expression to a binding. You can declare reusable pointcut expressions and name them and use them in boolean expressions in other pointcuts or bindings.
-
-!Examples
-Let's take a look at jboss-aop.xml.
-
-{{{
- <pointcut name="allPrivateMethodAndFields" expr="(execution(private * POJO->*(..)) OR field(private * POJO->*)) AND !execution(private void POJO->avoidMethod())"/>
-}}}
-
-This expression matches any private method or field, but not the POJO.avoidMethod(). It is a named pointcut and can be used in other epxressions.
-
-{{{
- <pointcut name="allPublicConstructors" expr="execution(public POJO->new(..))"/>
-}}}
-This expression matches any public constructor of the POJO class.
-
-{{{
- <bind pointcut="allPrivateMethodAndFields OR allPublicConstructors">
- <interceptor class="SimpleInterceptor"/>
- </bind>
-}}}
-
-The binding references these named pointcuts in a boolean expression. So the above would mean any private method or field access, but not avoidMethod() or any public constructor.
-
-!Running the example
-Running the example you'll see composition in action
-
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] <<< Entering SimpleInterceptor for: org.jboss.aop.joinpoint.ConstructorInvocation
- [java] empty constructor
- [java] <<< Entering SimpleInterceptor for: org.jboss.aop.joinpoint.FieldWriteInvocation
- [java] >>> Leaving SimpleInterceptor
- [java] <<< Entering SimpleInterceptor for: org.jboss.aop.joinpoint.MethodInvocation
- [java] privateMethod
- [java] >>> Leaving SimpleInterceptor
- [java] avoidMethod
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.publicMethod(); ---
- [java] publicMethod
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/constructor-execution/constructor.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/constructor-execution/constructor.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/constructor-execution/constructor.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,41 +0,0 @@
-!!!Constructor interception
-
-!Overview
-JBoss AOP allows you to insert behavior between the caller of a constructor and the actual constructor being called.
-If you look at {{Driver.java}} you will see that it is allocating a number of POJO objects by invoking different constructors declared in {{POJO.java}}. JBoss AOP allows you to intercept a constructor execution and transparently insert behavior when the constructor is invoked.
-
-!How do I apply an Interceptor to a constructor execution?
-To bind an interceptor to a constructor, you must create an XML file. Open up {{jboss-aop.xml}} and take a look. Let's apply {{ConstructorInterceptor.java}} to the {{public POJO(int i)}} constructor.
-{{{
-<aop>
- <bind pointcut="execution(POJO->new(int))">
- <interceptor class="ConstructorInterceptor"/>
- </bind>
-</aop>
-}}}
-To apply the interceptor you must create a binding and a ''pointcut'' that specifies where in your Java code you want the interceptor applied. ''execution(constructor expression)'' defines ''whenever the constructor is executed''. A constructor expression requires a class expression followed by '->' followed by 'new' followed by a list of parameters. You can optionally provide constructor attributes like 'public', 'static', etc. if so desired. You do not have to specify the entire signature of the constructor. It works in much the same way method expressions work.
-
-!Decomposing the Interceptor class
-When an intercepted constructor is executed, the AOP framework will call each bound interceptor in a chain within the same call stack. The Invocation object drives the chain. Interceptors call invocation.invokeNext() to proceed with the constructor invocation. After the chain is exhausted, Java reflection is called to execute the actual constructor. Because this is one call stack, you can place try/catch/finally blocks around invocation.invokeNext() to catch any exceptions thrown by the executed constructor if you so desired.
-
-Each type of intercepted execution (method, constructor, field, etc.) has a specific class that extends the base class {{org.jboss.aop.joinpoint.Invocation}}. If you open up {{ConstructorInterceptor.java}}, you will see that you can typecast the Invocation parameter into a {{org.jboss.aop.joinpoint.ConstructorInvocation}} object. The {{ConstructorInvocation}} class allows you to obtain additional information about the particular constructor call like the {{java.lang.reflect.Constructor}} object representing the call, the arguments.
-
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] empty constructor
- [java] --- new POJO(String); ---
- [java] String constructor
- [java] --- new POJO(int); ---
- [java] <<< Entering ConstructorInterceptor for: public POJO(int)
- [java] int constructor
- [java] >>> Leaving ConstructorInterceptor
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/declare/declare.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/declare/declare.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/declare/declare.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,232 +0,0 @@
-!!! Declare Error/Warning
-
-JBoss AOP can be used to enforce certain architectural constraints. The sample application in this example consists of a "business layer" (i.e {{Driver.java}}) which can call the "dao layer" (i.e. {{VehicleDAO}} and its subclasses {{MotorbikeDAO}} and {{CarDAO}}).
-
-{{VehicleDAO}} is an abstract class, and in our architecture for this small application we want to make sure that:
-*All subclasses of {{VehicleDAO}} implement a {{save()}} method.
-*The dao layer classes should not call back to the business layer classes (i.e. {{XXXDAO}} should not call {{Driver}})
-
-JBoss AOP allows you to check for this at instrumentation time, so if you are running precompiled AOP, the checks will be done at the aopc stage. If you are using loadtime AOP the checks will be performed when the class is first loaded.
-
-Two new XML tags are used for this {{declare-warning}} and {{declare-error}}, the only difference between them is that {{declare-error}} will throw an exception, causing execution to stop, while {{declare-warning}} prints out a warning message and continues as normal. Here is the jboss-aop.xml file used for this example:
-{{{
-<?xml version="1.0" encoding="UTF-8"?>
-<aop>
- <declare-warning expr="class($instanceof{VehicleDAO}) AND !has(public void *->save())">
- All VehicleDAO subclasses must override the save() method.
- </declare-warning>
- <declare-warning expr="call(Driver->new(..)) AND within(*DAO)">
- DAO classes should not access the Driver class
- </declare-warning>
- <declare-warning expr="call(* Driver->*(..)) AND withincode(* *DAO->*())">
- DAO classes should not access the Driver class
- </declare-warning>
-</aop>
-}}}
-
-*The first {{declare-warning}} tag specifies that {{VehicleDAO}} and its subclasses must implement a void noargs save() method. This condition is broken in our example by the fact that {{MotorbikeDAO}} does not do so.
-*The second {{declare-warning}} tag specifies that none of the DAO classes can call the Driver constructor. This condition is broken in our example by the fact that {{CarDAO.save()}} tries to create a new {{Driver}} class.
-*The third {{declare-warning}} tag specifies that no method on any of the the DAO classes can call the Driver methods. This condition is broken in our example by the fact that {{CarDAO.save()}} tries to call a method on the {{Driver}} class
-
-For pointcut expressions, only caller side pointcut expressions will work (so you cannot use {{all}}, {{execution}}, {{field}}, {{set}} or {{get}}).
-
-!Run the example compile-time instrumented
-
-Now if you run the example:
-
-To compile and run:
-{{{
- $ ant
-}}}
-
-It will generate the following output
-{{{
-$ ant
-Buildfile: build.xml
-
-prepare:
-
-compile40standalone:
- [javac] Compiling 1 source file to C:\cygwin\home\Kab\cvs\jboss-head\aop\docs\examples\declare
-
-compile:
- [aopc] WARNING: declare-warning condition
- [aopc] 'call(Driver->new(..)) AND within(*DAO)'
- [aopc] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] WARNING: declare-warning condition
- [aopc] 'call(* Driver->*(..)) AND withincode(* *DAO->save())'
- [aopc] was broken for method call:CarDAO.save()V calls Driver.method()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] WARNING: declare-warning condition
- [aopc] 'class($instanceof{VehicleDAO}) AND !has(public void *->save())'
- [aopc] was broken for class MotorbikeDAO
- [aopc] All VehicleDAO subclasses must override the save() method.
-
-
-
-
-run:
- [java] ---- Start ----
- [java] Car DAO save
-
-
-
-BUILD SUCCESSFUL
-}}}
-
-Note that when using compile time instrumentation the warnings are generated during the aopc phase.
-
-!Run the example load-time instrumented
-
-If you are running jdk 1.4 use:
-
-{{{
- $ ant run.40.instrumented
-}}}
-
-If you are running jdk 1.4 use:
-
-{{{
- $ ant run.50.instrumented
-}}}
-
-{{{
-Buildfile: build.xml
-
-prepare:
-
-compile40standalone:
-
-run.40.instrumented:
- [java] ---- Start ----
- [java] WARNING: declare-warning condition
- [java] 'call(Driver->new(..)) AND within(*DAO)'
- [java] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [java] DAO classes should not access the Driver class
-
- [java] WARNING: declare-warning condition
- [java] 'call(* Driver->*(..)) AND withincode(* *DAO->save())'
- [java] was broken for method call:CarDAO.save()V calls Driver.method()V
- [java] DAO classes should not access the Driver class
-
- [java] Car DAO save
- [java] WARNING: declare-warning condition
- [java] 'class($instanceof{VehicleDAO}) AND !has(public void *->save())'
- [java] was broken for class MotorbikeDAO
- [java] All VehicleDAO subclasses must override the save() method.
-
-
-
-
-BUILD SUCCESSFUL
-}}}
-Note that now the warnings are displayed when running the application, as the classes are transformed when loaded.
-
-!!declare-error
-If we replace all the {{declare-warning}} occurances with {{declare-error}} in jboss-aop.xml
-{{{
-<?xml version="1.0" encoding="UTF-8"?>
-<aop>
- <declare-error expr="class($instanceof{VehicleDAO}) AND !has(public void *->save())">
- All VehicleDAO subclasses must override the save() method.
- </declare-error>
- <declare-error expr="call(Driver->new(..)) AND within(*DAO)">
- DAO classes should not access the Driver class
- </declare-error>
- <declare-error expr="call(* Driver->*(..)) AND withincode(* *DAO->save())">
- DAO classes should not access the Driver class
- </declare-error>
-</aop>
-}}}
-
-!!declare-error precompiled
-When running precompiled we get:
-{{{
-Buildfile: build.xml
-
-prepare:
-
-compile40standalone:
-
-compile:
- [aopc] ERROR: declare-error condition
- [aopc] 'call(Driver->new(..)) AND within(*DAO)'
- [aopc] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] java.lang.RuntimeException: ERROR: declare-error condition
- [aopc] 'call(Driver->new(..)) AND within(*DAO)'
- [aopc] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [aopc] DAO classes should not access the Driver class
-
- [aopc] at org.jboss.aop.instrument.DeclareChecker.checkDeclares(DeclareChecker.java:124)
- [aopc] at org.jboss.aop.instrument.DeclareChecker.checkDeclares(DeclareChecker.java:57)
- [aopc] at org.jboss.aop.instrument.CallerTransformer$CallerExprEditor.edit(CallerTransformer.java:472)
- [aopc] at javassist.expr.ExprEditor.doit(ExprEditor.java:136)
- [aopc] at javassist.CtBehavior.instrument(CtBehavior.java:362)
- [aopc] at org.jboss.aop.instrument.CallerTransformer.applyCallerPointcuts(CallerTransformer.java:69)
- [aopc] at org.jboss.aop.instrument.Instrumentor.applyCallerPointcuts(Instrumentor.java:495)
- [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:562)
-...
-
-BUILD FAILED
-}}}
-
-See how the compiler stops at the first error and execution stops.
-
-!!declare-error loadtime
-When running with loadtime transformations we get:
-{{{
-$ ant run.40.instrumented
-Buildfile: build.xml
-
-prepare:
-
-compile40standalone:
-
-run.40.instrumented:
- [java] ---- Start ----
- [java] ERROR: declare-error condition
- [java] 'call(Driver->new(..)) AND within(*DAO)'
- [java] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [java] DAO classes should not access the Driver class
-
- [java] java.lang.RuntimeException: ERROR: declare-error condition
- [java] 'call(Driver->new(..)) AND within(*DAO)'
- [java] was broken for constructor call: CarDAO.save()V calls Driver.new()V
- [java] DAO classes should not access the Driver class
-
- [java] at org.jboss.aop.instrument.DeclareChecker.checkDeclares(DeclareChecker.java:124)
- [java] at org.jboss.aop.instrument.DeclareChecker.checkDeclares(DeclareChecker.java:57)
- [java] at org.jboss.aop.instrument.CallerTransformer$CallerExprEditor.edit(CallerTransformer.java:472)
- [java] at javassist.expr.ExprEditor.doit(ExprEditor.java:136)
- [java] at javassist.CtBehavior.instrument(CtBehavior.java:362)
- [java] at org.jboss.aop.instrument.CallerTransformer.applyCallerPointcuts(CallerTransformer.java:69)
- [java] at org.jboss.aop.instrument.Instrumentor.applyCallerPointcuts(Instrumentor.java:495)
- [java] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:562)
- [java] at org.jboss.aop.AspectManager.translate(AspectManager.java:564)
- [java] at org.jboss.aop.AspectManager.transform(AspectManager.java:482)
- [java] at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
- [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- [java] at java.lang.reflect.Method.invoke(Method.java:585)
- [java] at org.jboss.aop.standalone.SystemClassLoader.loadClass(SystemClassLoader.java:174)
- [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
- [java] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
- [java] at Driver.createVehicles(Driver.java:24)
- [java] at Driver.main(Driver.java:19)
- [java] [error] failed to transform: CarDAO.. Do verbose mode if you want full stack trace.
- [java] Exception in thread "main" java.lang.Error: Error transforming the class CarDAO: java.lang.RuntimeException: failed to transform: CarDAO
- [java] at org.jboss.aop.standalone.SystemClassLoader.loadClass(SystemClassLoader.java:191)
- [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
- [java] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
- [java] at Driver.createVehicles(Driver.java:24)
- [java] at Driver.main(Driver.java:19)
-
-
-
-BUILD FAILED
-}}}
-Again you can see how the first broken condition causes execution to stop.
Deleted: projects/aop/trunk/aop/docs/examples/dynamic-aop/dynamic.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/dynamic-aop/dynamic.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/dynamic-aop/dynamic.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,69 +0,0 @@
-!!!Dynamic AOP
-
-!Overview
-JBossAOP has a few features for Dynamic AOP. What is Dynamic AOP? It is two things
-
-* __Per Instance Interception__. The ability to do more fine grained bindings at the instance level. So that two instances of the same class can have two separate interceptor/advice chains.
-* __Hot Deployment__. The ability to add and remove advice bindings at runtime to any prepared Java class.
-
-!Prepare
-In order to use dynamic AOP, classes must first be "prepared". The preparation phase requires XML that tells the AOPC or AOP SystemClassLoader to do some simple bytecode manipulation on the prepared class so that it can do dynamic aop. This transformation is the same as any transformation triggered by a regular binding, except that no advince bindings are required. This added bytecode has low overhead. Run the Benchmark example to see how high the overhead is. For this example, open up jboss-aop.xml to see how the files are prepared
-
-{{{
- <prepare expr="all(POJO)"/>
-}}}
-This expression simple states to prepare all constructor, method, and field access to be AOPable. Actually, any <pointcut> or <bind> expression will cause a Java class to be "prepared".
-
-!Per Instance Interception
-Let's look at the first type of Dynamic AOP. You can add interceptors on a per instance basis using the {{org.jboss.aop.InstanceAdvisor}} API. (see the javadocs). All "prepared" java classes implement {{org.jboss.aop.Advised}}. Advised has a method _getInstanceAdvisor that gives you access to the InstanceAdvisor api. Added interceptors are put before and after the main ClassAdvisor interceptor chain. InstanceAdvisor.insertInterceptor puts an interceptor at the beginning of the advice/interceptor chain. InstanceAdvisor.appendInterceptor puts it at the end. Another quirkiness about this api is that the interceptors will be added to every chain of every method, field, or constructor so the added interceptor must do a runtime check to determine if it should execute or not. In the future we plan to have more fine-grained control over this, but we didn't get to it in the 1.0Beta release, sorry!
-
-You can see this in action within Driver.java
-{{{
- System.out.println("--- adding instance interceptors ---");
- Advised advised = (Advised)pojo;
- advised._getInstanceAdvisor().insertInterceptor(new InstanceInterceptor());
-}}}
-
-Driver.java typecasts the pojo instance to Advised. From the Advised interface, the code gets access to the InstanceAdvisor API and inserts an interceptor.
-
-!Hot Deployment
-Another thing to notice in the Driver.java source file is that the code is creating an AdviceBinding at runtime and applying it to the POJO class.
-
-{{{
- AdviceBinding binding = new AdviceBinding("execution(POJO->new(..))", null);
- binding.addInterceptor(SimpleInterceptor.class);
- AspectManager.instance().addBinding(binding);
-}}}
-
-You can also remove bindings at runtime as well through the AspectManager class. See javadocs for more detail.
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] in empty constructor
- [java] --- adding instance interceptors ---
- [java] --- pojo.counter++; ---
- [java] <<< Entering Instancenterceptor for: org.jboss.aop.joinpoint.FieldReadInvocation
- [java] <<< Entering Instancenterceptor for: org.jboss.aop.joinpoint.FieldWriteInvocation
- [java] --- pojo.someMethod(); ---
- [java] <<< Entering Instancenterceptor for: org.jboss.aop.joinpoint.MethodInvocation
- [java] in someMethod
- [java] --- new POJO(); ---
- [java] <<< Entering Simplenterceptor for: org.jboss.aop.joinpoint.ConstructorInvocation
- [java] in empty constructor
- [java] --- adding instance interceptors ---
- [java] --- pojo.counter++; ---
- [java] <<< Entering Instancenterceptor for: org.jboss.aop.joinpoint.FieldReadInvocation
- [java] <<< Entering Instancenterceptor for: org.jboss.aop.joinpoint.FieldWriteInvocation
- [java] --- pojo.someMethod(); ---
- [java] <<< Entering Instancenterceptor for: org.jboss.aop.joinpoint.MethodInvocation
- [java] in someMethod
-}}}
-
-
Deleted: projects/aop/trunk/aop/docs/examples/dynamic_cflow/cflow.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/dynamic_cflow/cflow.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/dynamic_cflow/cflow.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,52 +0,0 @@
-!!!Dynamic Control Flow
-
-!Overview
-Control flow is a runtime construct. A dynamic cflow will be called before the execution of the advices/interceptors it wraps. If it returns true then the advices execution. It allows you to do runtime dynamic checks at runtime to determine whether or not you want to run an advice stack.
-
-!Step One
-To implement a Dynamic CFlow you first need to implement org.jboss.aop.pointcut.DynamicCFlow
-
-{{{
-public interface DynamicCFlow
-{
- boolean shouldExecute(Invocation invocation);
-}
-}}}
-
-Put in the logic you want to run at runtime into the shouldExecution method.
-
-!Step Two
-Step two is to declare the Dynamic CFlow in the AOP XML file. See jboss-aop.xml:
-
-{{{
- <dynamic-cflow name="simple" class="SimpleDynamicCFlow"/>
-}}}
-
-Then you can use the dynamic cflow in any cflow expression. The cflow will be allocate once and only once for the entire VM.
-
-!Configure with XML
-If you want to do some XML configuration of the dynamic cflow instance, you can have it implement org.jboss.util.xml.XmlLoadable.
-
-{{{
-public interface XmlLoadable
-{
- public void importXml(Element element);
-}
-}}}
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo.method4(); ---
- [java] method1
- [java] --- turn on cflow ---
- [java] <<< Entering SimpleInterceptor for: public void POJO.method1()
- [java] method1
- [java] >>> Leaving SimpleInterceptor
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/examples.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/examples.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/examples.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,55 +0,0 @@
-!!!Tutorial
-
-This directory contains sample programs to test drive JBossAOP. They should probably be run in order, but feel free to skip around.
-
-!! XML examples
-
-The XML examples give a fuller coverage of the features of the AOP framework
-
-* [Method execution|method-execution/methodexecution.html]
-* [Field execution|field-execution/field.html]
-* [Constructor execution|constructor-execution/constructor.html]
-* [The all syntax|all/all.html]
-* [Stacks|stacks/stacks.html]
-* [Caller pointcuts|caller/caller.html]
-* [Instanceof|instanceof/instanceof.html]
-* [Implements|implements/implements.html]
-* [JDK 1.5 Annotations|annotation/annotation.html]
-* [JDK 1.5 Annotations with JDK 1.4|annotation14/annotation.html]
-* [JBoss AOP metadata|metadata/metadata.html]
-* [Control flow|cflow/cflow.html]
-* [Dynamic control flow|dynamic_cflow/cflow.html]
-* [Compositional and named pointcuts|composition/composition.html]
-* [Aspects and around advices|aspect/aspect.html]
-* [Before and after advices|beforeafter/beforeafter.html]
-* [Annotated advice parameters|annotated-parameters/annotated-parameters.html]
-* [Advice return types|return-types/return-types.html]
-* [After-throwing advices|after-throwing/after-throwing.html]
-* [Overloaded advices|overloaded-advices/overloaded-advices.html]
-* [Interceptor precedence|precedence/precedence.html]
-* [Introductions|introductions/introductions.html]
-* [Annotation introductions|annotation-introductions/annotation.html]
-* [Dynamic AOP|dynamic-aop/dynamic.html]
-* [Packaging|packaging/packaging.html]
-* [The has and hasfield operator|ioc_with_has/has.html]
-* [Typedefs|typedef/typedef.html]
-* [Packaging for JBoss|injboss/aopInJbossPackaging.html]
-* [JavaBean-style config of aspects|beanstyleconf/config.html]
-* [Declare error/warning|declare/declare.html]
-
-!! Annotation examples
-
-The annotation examples are shorter, since they assume you have already been through the XML examples and already understand the AOP basics. Their aim is to introduce you to how to achieve the same using JDK 5.0 annotations. __To run them you will need to set up your environment so that you are running JDK 5.0__
-
-* [Annotated interceptors|annotated-interceptors/annotated-interceptors.html]
-* [Annotated aspects|annotated-aspects/annotated-aspects.html]
-* [Annotated composition|annotated-composition/annotated-composition.html]
-* [Annotated typedefs|annotated-typedef/annotated-typedef.html]
-* [Annotated cflow|annotated-cflow/annotated-cflow.html]
-* [Annotated dynamic cflow|annotated-dynamic-cflow/annotated-dynamic-cflow.html]
-* [Annotated precedence|annotated-precedence/annotated-precedence.html]
-* [Annotated introductions|annotated-introduction/annotated-introduction.html]
-* [Annotated declare error/warning|annotated-declare/annotated-declare.html]
-* [Annotated packaging for JBoss|annotated-injboss/annotated-injboss.html]
-
-Enjoy
Deleted: projects/aop/trunk/aop/docs/examples/field-execution/field.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/field-execution/field.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/field-execution/field.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,64 +0,0 @@
-!!!Field interception
-
-!Overview
-JBoss AOP allows you to intercept a field access and insert behavior their.
-If you look at {{Driver.java}} and {{POJO.java}} you will see that they are accessing a number of fields.
-
-!How do I apply an Interceptor to a field execution?
-To bind an interceptor to the access of a field, you must create an XML file. Open up {{jboss-aop.xml}} and take a look. Let's take a look at the first bindings.
-{{{
-<aop>
-...
- <bind pointcut="get(private java.lang.String POJO->var1)">
- <interceptor class="GetInterceptor"/>
- </bind>
-...
-</aop>
-}}}
-This bindings states that when POJO.var1 is accessed for a read, invoke the GetInterceptor.
-
-The next one is:
-{{{
-...
- <bind pointcut="set(private java.lang.String POJO->var2)">
- <interceptor class="SetInterceptor"/>
- </bind>
-...
-}}}
-Whenever the field POJO.var2 is written to, invoke the SetInterceptor.
-
-The next one is:
-{{{
-...
- <bind pointcut="field(public static * POJO->*)">
- <interceptor class="FieldInterceptor"/>
- </bind>
-...
-}}}
-Whenever any public static field in POJO is accessed for a read or a write, call the FieldInterceptor. The ''field'' expression matches both get/set of a field.
-
-!Running
-Let's try these babies out....
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo.getVar1(); ---
- [java] <<< Entering GetInterceptor for: var1
- [java] >>> Leaving GetInterceptor
- [java] hello
- [java] --- pojo.setVar2(); ---
- [java] <<< Entering SetInterceptor for: var2
- [java] >>> Leaving SetInterceptor
- [java] --- pojo.getVar2(); ---
- [java] world
- [java] --- POJO.var3++; ---
- [java] <<< Entering FieldInterceptor for: var3 type: org.jboss.aop.joinpoint.FieldReadInvocation
- [java] >>> Leaving FieldInterceptor
- [java] <<< Entering FieldInterceptor for: var3 type: org.jboss.aop.joinpoint.FieldWriteInvocation
- [java] >>> Leaving FieldInterceptor
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/implements/implements.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/implements/implements.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/implements/implements.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,56 +0,0 @@
-!!!Implements/Implementing
-
-Sometimes when using $instanceof{}, you might just be interested in the methods coming from the implemented interface. There are two keywords that can be used in place of a method expression to
-acheive this:
-
-* $implements{} - matches the methods from the interface(s) listed, but ignores any super interfaces
-* $implementing{} - matches the methods from the interface(s) listed AND their super interfaces
-
-In this example ImplementsInterface extends ImplementsSuperInterface, and ImplementingInterface extends ImplementingSuperInterface.
-{{{
-<aop>
- <interceptor class="implementz.TestInterceptor"/>
- <bind pointcut="execution(void $instanceof{implementz.ImplementsInterface}->$implements{implementz.ImplementsInterface}(..))">
- <interceptor-ref name="implementz.TestInterceptor"/>
- </bind>
- <bind pointcut="execution(void $instanceof{implementz.ImplementingInterface}->$implementing{implementz.ImplementingInterface}(..))">
- <interceptor-ref name="implementz.TestInterceptor"/>
- </bind>
-</aop>
-}}}
-
-So for these bindings we will intercept our POJO class on all the methods coming from ImplementsInterface, i.e. {{methodsFromImplements()}}, and all methods coming from ImplementingInterface and ImplementingInterface's super interfaces, i.e. {{methodFromImplementingSuper()}} and {{methodFromImplementsSuper()}}.
-
- Note that if your class implements several interfaces, you can specify more than one interface in the $implements{}, $implementing{} list, as shown in this example pointcut expression:
- {{{
- execution(void $instanceof{X}->$implementing{X,Y,Z}(..))
- }}}
-
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- POJO ---
- [java] --- POJO.methodFromImplements ---
- [java] <<< TestInterceptor intercepting
- [java] *** POJO methodFromImplements
- [java] >>> Leaving Trace
- [java] --- POJO.methodFromImplementingSuper (should not intercept) ---
- [java] *** POJO methodFromImplementsSuper
- [java] --- POJO.methodFromImplementing ---
- [java] <<< TestInterceptor intercepting
- [java] *** POJO methodFromImplementing
- [java] >>> Leaving Trace
- [java] --- POJO.methodFromImplementingSuper ---
- [java] <<< TestInterceptor intercepting
- [java] *** POJO methodFromImplementingSuper
- [java] >>> Leaving Trace
- [java] --- POJO.ownMethod (should not intercept) ---
- [java] *** POJO ownMethod
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/injboss/aopInJbossPackaging.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/injboss/aopInJbossPackaging.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/injboss/aopInJbossPackaging.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,454 +0,0 @@
-!!! Running and packaging in JBoss
-__To run these examples you must edit build.xml and set the jboss.dir to where JBoss is. The server configuration used in this example is 'all', so you must start JBoss with 'run -c all'. __
-You can change the server configuration used by modifying the jboss.server.config property in build.xml. If you use the 'default' server configuration, you will get error messages on startup. They are not "harmful", more info about these can be found [here|http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846940#3846940]
-
-There are several ways to package classes to be run with AOP in JBoss, and this page takes you through a few of the options available to you.
-
-All the examples shown here use loadtime transformations, so you will need to modify your jboss/server/--yourconfig--/conf/jboss-service.xml as outlined in [Running with JBoss Application Server|../../reference/en/html/running.html#jboss]
-
-A simple application is that comes in a web-application and a full J2EE app flavour is used to illustrate how it can be pacaged in different ways to acheive the same thing.
-
-The source class/package structure is
-
-{{{
- org
- |
- - jboss
- |
- - injbossaop
- |
- - ejb (Only used in EAR version)
- | |
- | - ExampleSession
- | - ExampleSessionBean
- | - ExampleSessionHome
- |
- -lib
- | |
- | - ExampleValue
- | - SimpleInterceptor
- |
- |-mbean
- |
- - Standard
- - StandardMBean
- |
- |
- |-web
- |
- - BasicExampleServlet (Used for WAR version)
- - EarExampleServlet (USed for EAR version)
-
-
-
-}}}
-
-Both examples use the same jboss-aop.xml file
-{{{
-<?xml version="1.0" encoding="UTF-8"?>
-<aop>
- <bind pointcut="all(org.jboss.injbossaop.lib.ExampleValue)">
- <interceptor class="org.jboss.injbossaop.lib.SimpleInterceptor"/>
- </bind>
-
- <typedef name="MyServlets" expr="class($instanceof{javax.servlet.http.HttpServlet}) AND class(org.jboss.injbossaop.web.*)"/>
- <bind pointcut="all($typedef{MyServlets})">
- <interceptor class="org.jboss.injbossaop.lib.SimpleInterceptor"/>
- </bind>
-
- <bind pointcut="all($typedef{MyServlets})">
- <interceptor class="org.jboss.injbossaop.lib.SimpleInterceptor"/>
- </bind>
-
- <typedef name="MySessionBeans" expr="class($instanceof{javax.ejb.SessionBean}) AND class(org.jboss.injbossaop.ejb.*)" />
- <bind pointcut="all($typedef{MySessionBeans})">
- <interceptor class="org.jboss.injbossaop.lib.SimpleInterceptor"/>
- </bind>
-
- <bind pointcut="all(org.jboss.injbossaop.mbean.*)">
- <interceptor class="org.jboss.injbossaop.lib.SimpleInterceptor"/>
- </bind>
-</aop>
-
-}}}
-
-
-
-__War functionality__
-
-[http://localhost:8080/aopexample/index.jsp|http://localhost:8080/aopexample/index.jsp]
- gets ExampleValue from session, calls getMessage() on it, and displays the value.
-
-You can fill in a value in the textbox and press submit. The call goes to
-{{{
- BasicExampleServlet.service()
- creates a new ExampleValue with the passed in string and sets that in the session
- forwards to index.jsp for display
-}}}
-
-index.jsp then gets ExampleValue from session, calls getMessage() on it, and displays the value.
-
-The output in the JBoss logs for all the WAR examples will be something like:
--For initial display of index.jsp page
-{{{
- 21:34:14,929 INFO [STDOUT] **** ExampleValue empty Constructor
- 21:34:14,939 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue_getMessage_53534
- 07034680111516_OptimizedMethodInvocation
- type: Method Invocation
- method: getMessage
- Class containing method: org.jboss.injbossaop.lib.ExampleValue
- 21:34:14,939 INFO [STDOUT] **** ExampleValue.getMessage()
- 21:34:14,939 INFO [STDOUT] >>> Leaving SimpleInterceptor
-}}}
--Having filled in a value and pressed submit, you should get
-{{{
- 21:34:33,525 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.web.BasicExampleServlet_service_8
- 586428322187484014_OptimizedMethodInvocation
- type: Method Invocation
- method: service
- Class containing method: org.jboss.injbossaop.web.BasicExampleServlet
- 21:34:33,525 INFO [STDOUT] **** BasicExampleServlet.service()
- 21:34:33,535 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue1OptimizedConstru
- ctorInvocation
- type: Constructor Invocation
- constructor: public org.jboss.injbossaop.lib.ExampleValue(java.lang.Stri
-ng)
- 21:34:33,535 INFO [STDOUT] **** ExampleValue String Constructor
- 21:34:33,535 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:34:33,625 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue_getMessage_53534
- 07034680111516_OptimizedMethodInvocation
- type: Method Invocation
- method: getMessage
- Class containing method: org.jboss.injbossaop.lib.ExampleValue
- 21:34:33,625 INFO [STDOUT] **** ExampleValue.getMessage()
- 21:34:33,625 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:34:33,625 INFO [STDOUT] >>> Leaving SimpleInterceptor
-}}}
-
-
-__Ear functionality__
-
-
-[http://localhost:8080/aopexample/index.jsp|http://localhost:8080/aopexample/index.jsp]
- gets ExampleValue from session, calls getMessage() on it, and displays the value.
-
-You can fill in a value in the textbox and press submit. This works similar to the war example apart from that the servlet used is EarExampleServlet which calls through to the ExampleSession SLSB, which creates the message. The call goes to
-{{{
- EarExampleServlet.service()
- Looks up ExampleSessionHome, calls create() and calls ExampleSession.getValue() with the passed in String
-
- ExampleSession.getValue()
- creates a new ExampleValue with the passed in string and returns that
-
- EarExampleServlet.service()
- sets the ExampleValue in the session and forwards to index.jsp for display
-}}}
-
-
-index.jsp then gets ExampleValue from session, calls getMessage() on it, and displays the value.
-
-
-The output in the JBoss logs for all the EAR examples will be something like:
--For initial display of index.jsp page
-{{{
- 21:26:26,305 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.web.EarExampleServlet_service_858
- 6428322187484014_OptimizedMethodInvocation
- type: Method Invocation
- method: service
- Class containing method: org.jboss.injbossaop.web.EarExampleServlet
- 21:26:00,447 INFO [STDOUT] **** ExampleValue.getMessage()
- 21:26:00,447 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:08:19,332 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue$ExampleValue_mes
- sage_632994_OptimizedSetFieldInvocation
- type: Field Write Invocation
- field: java.lang.String org.jboss.injbossaop.lib.ExampleValue.message
- 21:08:19,332 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:08:19,332 INFO [STDOUT] **** ExampleValue empty Constructor
- 21:08:19,332 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue_getMessage_53534
- 07034680111516_OptimizedMethodInvocation
- type: Method Invocation
- method: getMessage
- Class containing method: org.jboss.injbossaop.lib.ExampleValue
- 21:08:19,332 INFO [STDOUT] **** ExampleValue.getMessage()
- 21:08:19,332 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue$ExampleValue_mes
- sage_32604882_OptimizedGetFieldInvocation
- type: Field Write Invocation
- field: java.lang.String org.jboss.injbossaop.lib.ExampleValue.message
- 21:08:19,332 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:08:19,332 INFO [STDOUT] >>> Leaving SimpleInterceptor
-}}}
--Having filled in a value and pressed submit, you should get (a bit longer this time)
-{{{
- 21:26:36,730 INFO [STDOUT] **** EarExampleServlet.service()
- 21:26:36,950 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.ejb.ExampleSessionBean_getValue_8
- 555731906870343793_OptimizedMethodInvocation
- type: Method Invocation
- method: getValue
- Class containing method: org.jboss.injbossaop.ejb.ExampleSessionBean
- 21:26:36,950 INFO [STDOUT] *** ExampleSessionBean.getValue()
- 21:26:36,960 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue1OptimizedConstru
- ctorInvocation
- type: Constructor Invocation
- constructor: public org.jboss.injbossaop.lib.ExampleValue(java.lang.Stri
- ng)
- 21:26:36,960 INFO [STDOUT] **** ExampleValue String Constructor
- 21:26:36,960 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:26:36,960 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:26:36,960 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue1OptimizedConstru
- ctorInvocation
- type: Constructor Invocation
- constructor: public org.jboss.injbossaop.lib.ExampleValue(java.lang.Stri
- ng)
- 21:26:36,960 INFO [STDOUT] **** ExampleValue String Constructor
- 21:26:36,960 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:26:37,050 INFO [STDOUT] <<< Entering SimpleInterceptor:
- invocation class: org.jboss.injbossaop.lib.ExampleValue_getMessage_53534
- 07034680111516_OptimizedMethodInvocation
- type: Method Invocation
- method: getMessage
- Class containing method: org.jboss.injbossaop.lib.ExampleValue
- 21:26:37,050 INFO [STDOUT] **** ExampleValue.getMessage()
- 21:26:37,050 INFO [STDOUT] >>> Leaving SimpleInterceptor
- 21:26:37,060 INFO [STDOUT] >>> Leaving SimpleInterceptor
-}}}
-
-
-!!Now for the interesting bit - how is it all packaged?
-
-Before running the examples, open the local.properties file and set jboss.dir to
-point to your JBoss distribution.
-
-!!WAR examples
-
-We'll start off looking at a few ways you can package a war file.
-
-__Standard WAR with stand-alone jboss-aop.xml file__
-
-__Note__ ''Due to changes in the default web classloader settings from JBoss 4.0.2 onwards, which effectively mean that jars in WEB-INF/lib directory and classes in the WEB-INF/classes directory do not get transformed, for this example to work you must set the UseJBossClassLoader attribute to true in the {{jboss.web:service=WebServer}} service. You can either do this by''
-*''Modifying the setting in {{JBOSS_HOME}}/server/all/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml}} before starting JBoss''
-*''Modifying the setting using the [JMX Console|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.web%3Aservice%3DWebServer]''
-
-
-''An alternative is to package your application as shown further below in the "WAR and .aop lib file contained in a JAR" example.
-__The above only applies to this current example__''
-
-If you run
-$ant deploy-basic-lt-war
-
-two files get deployed: jboss-aop.xml and aopexample.war
-aopexample.war is a bog-standard war file. It contains
-{{{
- index.jsp
- WEB-INF/web.xml
- WEB-INF/lib/aopexamplelib.jar
-}}}
-
-aopexamplelib.jar contains:
-{{{
- org/jboss/injbossaop/lib/ExampleValue.class
- org/jboss/injbossaop/lib/SimpleInterceptor.class
- org/jboss/injbossaop/mbean/Standard.class (Never called in this example)
- org/jboss/injbossaop/mbean/StandardMBean.class (Never called in this example)
- org/jboss/injbossaop/web/BasicExampleServlet.class
- org/jboss/injbossaop/web/EarExampleServlet.class (Never called in this example)
-
- org/jboss/injbossaop/ejb/ExampleSession.class (Never called in this example)
- org/jboss/injbossaop/ejb/ExampleSessionBean.class (Never called in this example)
- org/jboss/injbossaop/ejb/ExampleSessionHome.class (Never called in this example)
-}}}
-
-The magic comes from deploying the jboss-aop.xml file BEFORE the war is deployed
-
-
-
-__WAR and .aop lib file contained in a SAR__
-
-If you run
-$ ant deploy-basic-lt-war-in-sar
-
-Only one file gets deployed: aopexample.sar.
-
-aopexample.sar contains:
-{{{
- aopexample.war
- aopexamplelib.aop
- META-INF/jboss-service.xml
-}}}
-
-aopexample.war contains
-{{{
- index.jsp
- WEB-INF/web.xml
-}}}
-
-aopexamplelib.aop contains more or less the same as aopexamplelib, but contains a META-INF/jboss.aop file:
-{{{
- org/jboss/injbossaop/lib/ExampleValue.class
- org/jboss/injbossaop/lib/SimpleInterceptor.class
- org/jboss/injbossaop/mbean/Standard.class
- org/jboss/injbossaop/mbean/StandardMBean.class
- org/jboss/injbossaop/web/BasicExampleServlet.class
- org/jboss/injbossaop/web/EarExampleServlet.class (Never called in this example)
-
- org/jboss/injbossaop/ejb/ExampleSession.class (Never called in this example)
- org/jboss/injbossaop/ejb/ExampleSessionBean.class (Never called in this example)
- org/jboss/injbossaop/ejb/ExampleSessionHome.class (Never called in this example)
- META-INF/jboss-aop.xml
-}}}
-
-
-__WAR and .aop lib file contained in a JAR__
-
-If you run
-$ ant deploy-basic-lt-war-in-jar
-
-Only one file gets deployed: aopexample.jar.
-
-aopexample.jar contains:
-{{{
- aopexample.war
- aopexamplelib.aop
-}}}
-
-aopexample.war contains
-{{{
- index.jsp
- WEB-INF/web.xml
-}}}
-
-aopexamplelib.aop contains more or less the same as aopexamplelib, but contains a META-INF/jboss.aop file:
-{{{
- org/jboss/injbossaop/lib/ExampleValue.class
- org/jboss/injbossaop/lib/SimpleInterceptor.class
- org/jboss/injbossaop/mbean/Standard.class (Never called in this example)
- org/jboss/injbossaop/mbean/StandardMBean.class (Never called in this example)
- org/jboss/injbossaop/web/BasicExampleServlet.class
- org/jboss/injbossaop/web/EarExampleServlet.class (Never called in this example)
-
- org/jboss/injbossaop/ejb/ExampleSession.class (Never called in this example)
- org/jboss/injbossaop/ejb/ExampleSessionBean.class (Never called in this example)
- org/jboss/injbossaop/ejb/ExampleSessionHome.class (Never called in this example)
- META-INF/jboss-aop.xml
-}}}
-
-
-
-
-!!EAR examples
-
-Now let's take a look at a few ways to package ear files.
-
-__Standard EAR with standalone jboss-aop.xml file__
-
-If you run
-$ ant deploy-ear
-
-two files get deployed: jboss-aop.xml and aopexample.ear.
-
-aopexample.ear contains:
-{{{
- aopexample.war
- aopexampleejb.jar
- aopexamplelib.jar
- META-INF/application.xml
-}}}
-
-aopexample.war contains
-{{{
- index.jsp
- WEB-INF/web.xml
-}}}
-
-aopexampeejb.jar contains:
-{{{
- org/jboss/injbossaop/ejb/ExampleSession.class
- org/jboss/injbossaop/ejb/ExampleSessionBean.class
- org/jboss/injbossaop/ejb/ExampleSessionHome.class
- META-INF/ejb-jar.xml
-}}}
-
-and, finally aopexamplelib.jar contains:
-{{{
- org/jboss/injbossaop/lib/ExampleValue.class
- org/jboss/injbossaop/lib/SimpleInterceptor.class
- org/jboss/injbossaop/mbean/Standard.class (Never called in this example)
- org/jboss/injbossaop/mbean/StandardMBean.class (Never called in this example)
- org/jboss/injbossaop/web/BasicExampleServlet.class (Never called in this example)
- org/jboss/injbossaop/web/EarExampleServlet.class
-}}}
-
-
-There's nothing special about the classes in the ear - the magic comes from deploying the jboss-aop.xml file BEFORE the ear is deployed
-
-
-__EAR containing .aop file__
-
-If you run
-$ ant deploy-ear-aop
-
-One file gets deployed: aopexample.ear.
-
-aopexample.ear contains:
-{{{
- aopexample.war
- aopexampleejb.jar
- aopexamplelib.aop
- META-INF/application.xml
-}}}
-
-aopexample.war contains:
-{{{
- index.jsp
- WEB-INF/web.xml
-}}}
-
-aopexampeejb.jar contains:
-{{{
- org/jboss/injbossaop/ejb/ExampleSession.class
- org/jboss/injbossaop/ejb/ExampleSessionBean.class
- org/jboss/injbossaop/ejb/ExampleSessionHome.class
- META-INF/ejb-jar.xml
-}}}
-
-and, finally aopexamplelib.aop contains:
-{{{
- org/jboss/injbossaop/lib/ExampleValue.class
- org/jboss/injbossaop/lib/SimpleInterceptor.class
- org/jboss/injbossaop/mbean/Standard.class (Never called in this example)
- org/jboss/injbossaop/mbean/StandardMBean.class (Never called in this example)
- org/jboss/injbossaop/web/BasicExampleServlet.class (Never called in this example)
- org/jboss/injbossaop/web/EarExampleServlet.class
- META-INF/jboss-aop.xml
-}}}
-
-This is pretty similar to what we had in the standard ear example, apart from that the lib file has now has an .aop extension, and contains a META-INF/jboss-aop.xml file. __NOTE: ALL__ the relevant files in the ear get transformed/intercepted. The jboss-aop.xml file resides in aopexamplelib.aop. aopexampleejb.jar contains ExampleSessionBean (i.e. it is outside of aopexamplelib.aop), but the call to ExampleSessionBean.getValue() still gets intercepted.
-
-__From JBoss 4.0.5, ear contents are deployed in the order they are listed in application.xml, so you need to make sure that the .aop file comes first for the bindings to be available as the ejb's and servlets get deployed.__
-
-!!SAR examples
-If you run If you run
-{{{
-$ ant deploy-basic-lt-war-in-sar
-}}}
-or
-{{{
-$ ant deploy-example-lt-sar
-}}}
-you can see examples of instrumenting a standard MBean. Go to
-[StandardMBean|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.aop.example%3Aname%3DStandardMBean]
-and set the fields values and invoke the method() operation, and you will see that the
-MBean calls get intercepted.
-
-
-
Deleted: projects/aop/trunk/aop/docs/examples/instanceof/instanceof.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/instanceof/instanceof.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/instanceof/instanceof.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,26 +0,0 @@
-!!!Instanceof
-
-You can use $instanceof{} expressions when specify the class of a method, constructor, or field. This is very useful when you want to specify bindings that are driven off of base classes or interfaces.
-
-{{{
-<aop>
- <bind pointcut="execution(void $instanceof{SomeInterface}->someMethod())">
- <interceptor class="SimpleInterceptor"/>
- </bind>
-</aop>
-}}}
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo.someMethod(); ---
- [java] <<< Entering SimpleInterceptor type: org.jboss.aop.joinpoint.MethodInvocation
- [java] someMethod
- [java] >>> Leaving SimpleInterceptor
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/introductions/introductions.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/introductions/introductions.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/introductions/introductions.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,102 +0,0 @@
-!!!Introductions
-
-!Overview
-JBossAOP has the ability to force a Java class to implement an interface. You can even specify a Mixin Class that will be instantiated and attached to an instance of that class. So, if you force a Java class to implement an interface, it can delegate an introduced methods of that interface to the Mixin class instance.
-
-!Making a non-serializable class Serializable
-Take a look at POJO.java. You will see that it is non-serializable. Then take a look jboss-aop.xml:
-{{{
- <introduction class="POJO">
- <interfaces>
- java.io.Serializable
- </interfaces>
- </introduction>
-}}}
-
-The first introduction declaration, introduces/forces POJO to implement Serializable. When the aopc compiler is run, it will transform POJO to implement that interface. If you used a decompiler to look at POJO.class, you would find that it implements Serializable. The ''class'' attribute can be any fully qualified class name. Wildcards are allowed. You can also insert in ''$instanceof{'' or an annotation expression i.e. ''@myannotation''.
-
-!Externalizable. Using a Mixin
-The next example forces POJO2 to implement Externalizable. Now, for this to work, POJO2 must implement the readExternal and writeExternal methods required by the Externalizable interface. These methods are provided by the POJO2ExternalizableMixin class. Take a look at the XML binding for this:
-
-{{{
- <introduction class="POJO2">
- <mixin>
- <interfaces>
- java.io.Externalizable
- </interfaces>
- <class>POJO2ExternalizableMixin</class>
- <construction>new POJO2ExternalizableMixin(this)</construction>
- </mixin>
- </introduction>
-}}}
-
-Most of this makes sense, but what is the <construction> element? Whenever a Mixin is introduced to a class, the AOP framework creates a field within that class that holds the instance of the Mixin. The <construction> tag allows you to initialize this instance. You can specify any Java code within the <construction> tag. It must be a one liner and you have to provide the fully qualified name of any class you use. So, the above <construction> tag allocates a POJO2ExternalizableMixin and passes in a this pointer. The this pointer is actually the instance of the class that the Mixin is being applied to. This allows the Mixin class to handle externalization.
-
-!Complex Expressions
-The ''class'' attribute of the introduction can only handle a single class expression. If you want a boolean expression, you can instead use the ''expr'' XML attribute. You can have any scoped boolean expression. The ''class(..)'' keyword will have a class expression within it. You can also specify a ''has'' or ''hasField'' expression as well. The example shows how to use the ''expr'' XML attribute.
-
-{{{
- <metadata tag="test" class="POJO3">
- <method expr="void method()"/>
- </metadata>
-
- <metadata tag="test2" class="POJO4">
- <class/>
- </metadata>
-}}}
-
-First we add some metadata to POJO3 and POJO4. Then we use these tags in our introduction expression:
-
-{{{
- <introduction expr="has(* *->@test(..)) OR class(@test2)">
- <interfaces>
- java.io.Serializable
- </interfaces>
- </introduction>
-}}}
-
-The ''expr'' states: Any class that has a method tagged as ''@test'' or any class that is itself tagged ''@test2''.
-
-!Running the example
-Driver.java drives the test. It does serializable by using java.rmi.MarshalledObject to create a copy of POJO and POJO2 in memory. The introductions will allow this code to work.
-
-First, try running the example without JBossAOP:
-{{{
-$ rm *.class
-$ javac *.java
-$ java Driver
-}}}
-
-You should see the following error:
-
-{{{
-C:\jboss\jboss-head\aop\tmp\docs\examples\introductions>java Driver
---- POJO ---
-Exception in thread "main" java.io.NotSerializableException: POJO
- at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
- at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
- at java.rmi.MarshalledObject.<init>(MarshalledObject.java:92)
- at Driver.main(Driver.java:8)
-}}}
-
-This is expected because POJO is not serializable. Now run it with introductions.
-
-{{{
-$ ant
-}}}
-
-The output should be:
-
-{{{
-run:
- [java] --- POJO ---
- [java] deserialized pojo.stuff: hello world
- [java] --- POJO2 ---
- [java] deserialized pojo2.stuff2: hello world
- [java] --- POJO3 ---
- [java] pojo3 introduction expression worked
- [java] --- POJO4 ---
- [java] pojo4 introduction expression worked
-}}}
-
-
Deleted: projects/aop/trunk/aop/docs/examples/ioc_with_has/has.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/ioc_with_has/has.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/ioc_with_has/has.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,31 +0,0 @@
-!!! The HAS and HASFIELD operator
-
-The HAS operator within a pointcut expression allows you to inquire about extra information of the pointcut's target class. Let's say you have an constructor execution pointcut:
-{{{
-execution(*->new(..))
-}}}
-
-You can add a HAS expression to narrow down the expression to include the execution of any constructor who's class has a method setValue:
-{{{
-execution(*->new(..)) AND has(void *->setValue(int))
-}}}
-
-You can also do the same with fields. Let's say we also wanted to narrow it down to all classes that have a Thread field:
-
-{{{
-execution(*->new(..)) AND hasfield(java.lang.Thread *.*)
-}}}
-
-!Inversion of Control
-
-How is this useful? A usecase is Inversion of Control (IoC). IoC is about injecting an object's depencies transparently. You could define an aspect that intercepted a constructor call, and on the return inject these dependencies into the object. The has operator allows you to do this and this is what the example program does.
-
-The example uses the following binding:
-{{{
- <bind pointcut="execution(*->new(..)) AND has(public void *->setInjectedParameter(int))">
- <interceptor class="DependencyInjectorInterceptor"/>
- </bind>
-}}}
-
-On any constructor call where the constructor's class has a public setInjectedParameter method, call the DependencyInjectorInterceptor. The DependencyInjectorInterceptor will call the constructed object's setInjectedParameter.
-
Deleted: projects/aop/trunk/aop/docs/examples/metadata/metadata.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/metadata/metadata.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/metadata/metadata.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,91 +0,0 @@
-!!!JBoss Metadata
-
-!Overview
-JBoss Metadata is alot like JDK 1.5's annotations([JSR-175|http://www.jcp.org/en/jsr/detail?id=175]) except it is driven and applied through XML. JBossAOP has the ability to define metadata in XML or as Doclet tags that are then parsed to generate XML when you are not using JDK 1.5 or higher. You can use the same pointcut annotation expressions to reference JBossAOP XML metadata expressions. This metadata is different than regular JDK annotations in that they are untyped. If you've read the [Annotations with JDK 1.4|../annotations14/annotation.html]. You can handcode this XML or have the Annotation compiler generate them from doclet tags using the -xml option.
-
-!Example code
-The example code applies 2 separate interceptors via tags supplied in a Java source file. One of the interceptors is a tracing interceptor that is trigger by a @trace annotation, the other is B2B functionality that will bill/charge a user for each access of the api. This is also triggered by an annotation.
-
-!Declaring annotations
-Open up POJO.java. This is the source file for where our annotations will be declared.
-__IMPORTANT NOTE!__ You MUST have a space after the annotation tag name otherwise you will get a compiler error.
-{{{
- /**
- * @@billable (amount=0.05)
- * @@trace
- */
- public void someMethod()
- {
- System.out.println("someMethod");
- }
-}}}
-
-JBossAOP tags are defined by a double at symbol '@@' and zero or more name/value pairs. In the above example, we are declaring someMethod() to be traced and billable to an ammount of $0.05 every time it is accessed. This Java source file is run through JBossAOP's annotation compiler to generate XML. You can run this annotation compiler as an ANT taskdef or standalone. Look at build.xml to see how the taskdef is set up for {{annotationc}}.
-
-The {{annotationc}} task is very similar to the {{javac}} taskdef. You declare {{<src>}} tags just as you would with {{javac}}. Any .java files in your sourcepath will be compiled and an XML file will be generated.
-
-When you run the build, metadata-aop.xml is generated. Take a look at that to see how the doclet tags are mapped to XML. It is pretty straightforward.
-
-!Annotations in pointcut expressions
-Annotations can be referenced by an '@' sign in pointcut expressions. They can only be used in the class expressions for a method, field, or constructor for execution and caller pointcuts. They can also be used in substitute for 'new' in constructor land, and for a method or field name. Take a look at jboss-aop.xml
-
-{{{
- <bind pointcut="execution(POJO->@billable(..))">
- <interceptor class="BillingInterceptor"/>
- </bind>
-
- <bind pointcut="execution(* POJO->@billable(..))">
- <interceptor class="BillingInterceptor"/>
- </bind>
-
-}}}
-
-The first binding above says that for every constructor tagged as @billable apply the BillingInterceptor. The second binding states that for any method tagged as @billable apply the BillingInterceptor. Let's now take a look at applying the tracing advice.
-
-{{{
- <bind pointcut="all(@trace)">
- <interceptor class="TraceInterceptor"/>
- </bind>
-}}}
-
-The above states that for any field, constructor, or method tagged as @trace, apply the TraceInterceptor.
-
-!Accessing metadata at runtime
-You can access metadata through the {{org.jboss.aop.Advised}} interface through the _getAdvisor() or _getInstanceAdvisor() methods, or you can use the indirection that the Invocation object provides you. You can use the Invocation object to resolve metadata based on the context of the execution. {{BillingInterceptor.java}} gives an example of this. This interceptor intercepts different kinds of things (methods and constructors), but it doesn't care about the thing it is intercepting, only the metadata.
-
-{{{
- public Object invoke(Invocation invocation) throws Throwable
- {
- System.out.println("billing amount: $" + invocation.getMetaData("billable", "amount"));
- }
-}}}
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will run the annotationc compiler on the source files to generate metadata in metadata-aop.xml, then javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. Note that there are two XML aop deployment descriptors: metadata-aop.xml and jboss-aop.xml. The System Property jboss.aop.path can accept a list of files delimited by the platform classpath separator. ';' on windows ':' on unix. Running the example should produce:
-
-{{{
-run:
- [java] --- new POJO(); ---
- [java] billing amount: $0.01
- [java] <<< Trace : executing constructor public POJO()
- [java] empty constructor
- [java] >>> Leaving Trace
- [java] --- new POJO(int); ---
- [java] billing amount: $0.01
- [java] <<< Trace : executing constructor public POJO(int)
- [java] int constructor
- [java] >>> Leaving Trace
- [java] --- pojo.someMethod(); ---
- [java] billing amount: $0.05
- [java] <<< Trace : executing method public void POJO.someMethod()
- [java] someMethod
- [java] >>> Leaving Trace
- [java] --- pojo.field = 55; ---
- [java] <<< Trace : write field name: public int POJO.field
- [java] >>> Leaving Trace
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/method-execution/methodexecution.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/method-execution/methodexecution.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/method-execution/methodexecution.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,97 +0,0 @@
-!!!Method interception
-
-!Overview
-JBoss AOP allows you to insert behavior between the caller of a method and the actual method being called.
-If you look at {{Driver.java}} you will see that it is invoking a number of methods declared in {{POJO.java}}. JBoss AOP allows you to intercept a method call and transparently insert behavior when the method is invoked.
-
-!What is an Interceptor?
-Behavior that you want to insert when a method is executed must be encapsulated in a implementation of the {{org.jboss.aop.advice.Interceptor}} interface. (''For those of you familiar with AOP terms, an Interceptor in JBoss is an aspect with only one advice.'')
-{{{
-package org.jboss.aop.advice;
-
-import org.jboss.aop.joinpoint.Invocation;
-
-public interface Interceptor
-{
- public String getName();
- public Object invoke(Invocation invocation) throws Throwable;
-}
-}}}
-
-When an AOP'ed method is called, JBoss will break up the method into its parts: a {{java.lang.reflect.Method}} object and an {{{Object[]}}} array representing the arguments of the method. These parts are encapsulated in an {{org.jboss.aop.joinpoint.Invocation}} object. {{SimpleInterceptor.java}} is a simple implementation of an interceptor.
-
-!How do I apply an Interceptor to a method execution?
-To bind an interceptor to a method execution, you must create an XML file. Open up {{jboss-aop.xml}} and take a look. Let's first start by applying {{SimpleInterceptor.java}} to the {{POJO.noop()}} method.
-{{{
-<aop>
-...
- <bind pointcut="execution(public void POJO->noop())">
- <interceptor class="SimpleInterceptor"/>
- </bind>
-...
-</aop>
-}}}
-To apply the interceptor you must create a binding and a ''pointcut'' that specifies where in your Java code you want the interceptor applied. ''execution(method expression)'' defines ''whenever the method noop() is executed''. A method expression requires a ''return type'' followed by a class expression followed by '->' followed by the method name followed by a list of parameters. You can optionally provide method attributes like 'public', 'static', etc. if so desired.
-
-!Method expressions
-You do not have to specify the entire signature of the method and can use wildcards anywhere you want. The next binding defined in {{jboss-aop.xml}} looks like this.
-{{{
- <bind pointcut="execution(* POJO->*(int))">
- <interceptor class="MethodInterceptor"/>
- </bind>
-}}}
-This binding says, whenever any POJO method that has one parameter that is an {{int}} is executed, invoke the {{MethodInterceptor}}. The next bindings shows another example.
-{{{
- <bind pointcut="execution(static * POJO->*(..))">
- <interceptor class="MethodInterceptor"/>
- </bind>
-}}}
-This binding says, whenever any static POJO method is executed invoke the {{MethodInterceptor}}
-
-{{{
- <bind pointcut="execution(* POJO$Bar->*(..))">
- <interceptor class="MethodInterceptor"/>
- </bind>
-}}}
-The above binding shows how to specify an inner class.
-
-!Decomposing the Interceptor class
-When an intercepted method is executed, the AOP framework will call each bound interceptor in a chain within the same call stack. The Invocation object drives the chain. Interceptors call invocation.invokeNext() to proceed with the method invocation. After the chain is exhausted, Java reflection is called to execute the actual method. Because this is one call stack, you can place try/catch/finally blocks around invocation.invokeNext() to catch any exceptions thrown by the executed method if you so desired.
-
-Each type of intercepted execution (method, constructor, field, etc.) has a specific class that extends the base class {{org.jboss.aop.joinpoint.Invocation}}. If you open up {{MethodInterceptor.java}}, you will see that you can typecast the Invocation parameter into a {{org.jboss.aop.joinpoint.MethodInvocation}} object. The {{MethodInvocation}} class allows you to obtain additional information about the particular method call like the {{java.lang.reflect.Method}} object representing the call, the arguments, and even the targetObject of the interception.
-
-
-!Configure with XML
-If you want to do some XML configuration of the interceptor instance, you can have it implement org.jboss.util.xml.XmlLoadable.
-
-{{{
-public interface XmlLoadable
-{
- public void importXml(Element element);
-}
-}}}
-
-!Running
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo.noop(); ---
- [java] <<< Entering SimpleInterceptor
- [java] noop()
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.test1(String param); ---
- [java] test1(String param): hello world
- [java] --- pojo.test1(int param); ---
- [java] <<< Entering MethodInterceptor for: public void POJO.test2(int)
- [java] test2(int param): 55
- [java] >>> Leaving MethodInterceptor
- [java] --- POJO.test2(); ---
- [java] <<< Entering MethodInterceptor for: public static void POJO.test2()
- [java] static method
- [java] >>> Leaving MethodInterceptor
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/overloaded-advices/overloaded-advices.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/overloaded-advices/overloaded-advices.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/overloaded-advices/overloaded-advices.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,226 +0,0 @@
-!!!Overloaded Advices
-
-!Overview
-In previous examples, we have seen that JBoss AOP supports different types of advices
-and that those can have several signatures. In this example, we will show
-how to expand that flexibility by binding pointcuts to overloaded advices.
-
-!Overloaded Advices vs. Nested If-Else Statements
-
-Overloaded advices can be useful to avoid nested if-else statements.
-Look at this version of {{JoinPointAspect.aroundAdvice}}:
-
-{{{
-public void aroundAdvice(Invocation invocation) throws Throwable
-{
- if (invocation instanceof ConstructorInvocation)
- {
- System.out.println(">>> aroundAdvice on constructor of class: " +
- (ConstructorInvocation) invocation).getConstructor().getDeclaringClass().getName());
- }
- else if (invocation instanceof MethodInvocation)
- {
- System.out.println(">>> aroundAdvice on method execution: " +
- ((MethodInvocation) invocation).getMethod().getName());
- }
- else if (invocation instanceof FieldReadInvocation)
- {
- System.out.println(">>> aroundAdvice on field read: " +
- ((FieldReadInvocation) invocation).getField().getName());
- }
- else if (invocation instanceof FieldWriteInvocation)
- {
- System.out.println(">>> aroundAdvice on field write: " +
- ((FieldWriteInvocation) invocation).getField().getName());
-
- }
- return invocation.invokeNext();
-}
-
-___________________________
-
-<bind pointcut="all(POJO)">
- <advice name="aroundAdvice" aspect="JoinPointAspect"/>
-</bind>
-}}}
-
-As you can see, {{aroundAdvice}} is a simple advice that logs constructor and method
-executions, field reads and field writes. Despite that, its implementation doesn't
-look so simple as a logging advice should be. This advice does a check on the
-{{invocation}} parameter type so it can display the correct message and access
-methods specific to the joinpoint type being intercepted. This can be avoided by
-overloading {{aroundAdvice}}, so that we have a version for each {{Invocation}} type:
-
-{{{
-public Object aroundAdvice(ConstructorInvocation invocation) throws Throwable
-{
- System.out.println(">>> aroundAdvice on constructor of class: " +
- invocation.getConstructor().getDeclaringClass().getName());
- return invocation.invokeNext();
-}
-
-public Object aroundAdvice(MethodInvocation invocation) throws Throwable
-{
- System.out.println(">>> aroundAdvice on method execution: " +
- invocation.getMethod().getName());
- return invocation.invokeNext();
-}
-
-public Object aroundAdvice(FieldReadInvocation invocation) throws Throwable
-{
- System.out.println(">>> aroundAdvice on field read: " +
- invocation.getField().getName());
- return invocation.invokeNext();
-}
-
-public Object aroundAdvice(FieldWriteInvocation invocation) throws Throwable
-{
- System.out.println(">>> aroundAdvice on field write: " +
- invocation.getField().getName());
- return invocation.invokeNext();
-}
-}}}
-
-The code above is much more cleaner, and now we can see more clearly that {{aroundAdvice}}
-just logs messages regarding the joinpoint being intercepted. Besides, using
-overloaded advices is more efficient than using nested if-else statements. JBoss AOP
-will call the correct advice version for each joinpoint type, avoiding the cost
-of checking the invocation type everytime this advice is invoked.
-
-This example could also be applied to another type of advice with minor changes:
-{{{
-public void otherTypeOfAdvice(@JoinPoint IConstructorInfo joinPoint)
-{
- System.out.println(">>> otherTypeOfAdvice on constructor of class: " +
- joinPoint.getConstructor().getDeclaringClass().getName());
-}
-
-public void otherTypeOfAdvice(@JoinPoint IMethodInfo joinPoint)
-{
- System.out.println(">>> otherTypeOfAdvice on method execution: " +
- joinPoint.getAdvisedMethod().getName());
-}
-
-public void otherTypeOfAdvice(@JoinPoint IFieldInfo joinPoint)
-{
- System.out.println(">>> otherTypeOfAdvice on field" +
- (joinPoint.isRead()? "read: ": "write: ") +
- joinPoint.getAdvisedField().getName());
-}
-
-___________________________
-
-<bind pointcut="all(POJO)">
- <before name="otherTypeOfAdvice" aspect="JoinPointAspect"/>
-</bind>
-}}}
-
-Notice that {{IFieldInfo}} is used fro both field read and write joinpoints. The
-{{otherTypeOfAdvice}} advice is applied as a before advice in the example. However,
-it could have been applied as an after advice, or a finally advice. And it could
-also have been applied as an after-throwing advice if we added a {{@Thrown}}
-parameter to all overloaded versions of this advice.
-
-You can find the overloaded implementations of {{aroundAdvice}} and
-{{otherTypeOfAdvice}} in the {{JoinPointAspect.java}} file.
-
-! Mixing Different Parameters
-
-Besides the previous examples, you can write overloaded advices using different
-return types and annotated parameters. Look at the following overloaded advice:
-
-{{{
-public int overloadedAdvice(@Target POJO target)
-{
- System.out.println(">>> overloadedAdvice: int(Target POJO)");
- return 0;
-}
-
-public void overloadedAdvice(@JoinPoint IConstructorInfo joinPoint)
-{
- System.out.println(">>> overloadedAdvice: (JoinPoint IConstructorInfo)");
-}
-
-public void overloadedAdvice(@Target Object target)
-{
- System.out.println(">>> overloadedAdvice: (Target Object)");
-}
-
-public void overloadedAdvice(@JoinPoint ICallerMethodInfo joinPoint, @Caller Driver driver)
-{
- System.out.println(">>> overloadedAdvice: (JoinPoint ICallerMethodInfo, Caller Driver)");
-}
-
-public void overloadedAdvice(@JoinPoint IJoinPointInfo joinPoint, @Arg String arg)
-{
- System.out.println(">>> overloadedAdvice: JoinPoint IJoinPoint, Arg String");
-}
-}}}
-
-{{MixedParametersAspect.overloadedAdvice()}} has five different versions, and each one
-receives different parameter types. In that case, JBoss AOP will try to find the most
-appropriate version for each case.
-
-Run the example to see how this advice is applied to the different POJO joinpoints.
-
-To see all rules JBoss AOP uses to pick an overloaded advice version, please, read
-the corresponding chapter of the Reference Manual.
-
-!Run the example
-
-__THIS EXAMPLE REQUIRES JDK 1.5!!__ To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode,
-then finally run the example. The output should read as follows:
-{{{
-run:
-
- [java] Calling POJO constructor
- [java] ========================
- [java] >>> otherTypeOfAdvice on constructor of class: POJO
- [java] >>> aroundAdvice on constructor of class: POJO
- [java] >>> overloadedAdvice: (JoinPoint IConstructorInfo)
-
- [java] Setting POJO->intField with 1751 value
- [java] ======================================
- [java] >>> otherTypeOfAdvice on fieldwrite: intField
- [java] >>> aroundAdvice on field write: intField
- [java] >>> overloadedAdvice: int(Target POJO)
-
- [java] Reading POJO->intField value
- [java] ============================
- [java] >>> otherTypeOfAdvice on fieldread: intField
- [java] >>> aroundAdvice on field read: intField
- [java] >>> overloadedAdvice: int(Target POJO)
-
- [java] Setting POJO->stringField with "text" value
- [java] ===========================================
- [java] >>> otherTypeOfAdvice on fieldwrite: stringField
- [java] >>> aroundAdvice on field write: stringField
- [java] >>> overloadedAdvice: JoinPoint IJoinPoint, Arg String
-
- [java] Reading POJO->stringField value
- [java] ===============================
- [java] >>> otherTypeOfAdvice on fieldread: stringField
- [java] >>> aroundAdvice on field read: stringField
- [java] >>> overloadedAdvice: (Target Object)
-
- [java] Calling POJO->voidMethod()
- [java] ==========================
- [java] >>> otherTypeOfAdvice on method execution: voidMethod
- [java] >>> aroundAdvice on method execution: voidMethod
- [java] RUNNING POJO->voidMethod()
- [java] >>> overloadedAdvice: int(Target POJO)
- [java] >>> overloadedAdvice: (JoinPoint ICallerMethodInfo, Caller Driver)
-
- [java] Calling POJO->methodWithStringArg()
- [java] ===================================
- [java] >>> otherTypeOfAdvice on method execution: methodWithStringArg
- [java] >>> aroundAdvice on method execution: methodWithStringArg
- [java] RUNNING POJO->methodWithStringArg("stringArg")
- [java] >>> overloadedAdvice: JoinPoint IJoinPoint, Arg String
- [java] >>> overloadedAdvice: (JoinPoint ICallerMethodInfo, Caller Driver)
-}}}
-
Deleted: projects/aop/trunk/aop/docs/examples/packaging/packaging.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/packaging/packaging.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/packaging/packaging.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,47 +0,0 @@
-!!!Packaging
-
-You do not always have to use the system property jboss.aop.path to specify JBossAOP XML files. By default, JBossAOP will also look in your classpath for any URL that matches META-INF/jboss-aop.xml.
-
-The example in this directly is take from the method-execution example. Instead of using declaring jboss.aop.path as a system property, this example instead packages up all the .class files in a jar along with META-INF/jboss-aop.xml in the resources directory.
-
-{{{
-C:\jboss\jboss-head\aop\tmp\docs\examples\packaging>jar -tf example.jar
-META-INF/
-META-INF/MANIFEST.MF
-Driver.class
-MethodInterceptor.class
-POJO$Bar.class
-POJO.class
-SimpleInterceptor.class
-META-INF/jboss-aop.xml
-}}}
-
-You can turn off this classpath behavior by using the jboss.aop.search.classpath=false system property. By default it is on. (FYI, it is off by default when running in the JBoss Application Server).
-
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- pojo.noop(); ---
- [java] <<< Entering SimpleInterceptor
- [java] noop()
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.test1(String param); ---
- [java] test1(String param): hello world
- [java] --- pojo.test1(int param); ---
- [java] <<< Entering MethodInterceptor for: public void POJO.test2(int)
- [java] test2(int param): 55
- [java] <<< Entering MethodInterceptor for: public void POJO$Bar.hello()
- [java] hello
- [java] >>> Leaving MethodInterceptor
- [java] >>> Leaving MethodInterceptor
- [java] --- POJO.test2(); ---
- [java] <<< Entering MethodInterceptor for: public static void POJO.test2()
- [java] static method
- [java] >>> Leaving MethodInterceptor
-}}}
Deleted: projects/aop/trunk/aop/docs/examples/precedence/precedence.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/precedence/precedence.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/precedence/precedence.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,106 +0,0 @@
-!!!Interceptor Precedence
-
-!Background
-In the other examples shown, the ordering of interceptors is according to how they are specified for each binding. This is fine for a lot of cases, but becomes a bit
-more problematic if you have several bindings resolving to each pointcut. Also, aspects defined using annotations (see reference documentation) have no notion
-of ordering, how they are ordered is completely random. To examine the case of XML, we have the following two bindings in our jboss-aop.xml file:
-
-{{{
-
- <bind pointcut="execution(POJO->new())">
- <interceptor-ref name="FirstInterceptor"/>
- <interceptor-ref name="SimpleInterceptor3"/>
- <interceptor-ref name="SimpleInterceptor2"/>
- <interceptor-ref name="SimpleInterceptor"/>
- </bind>
-
- <bind pointcut="execution(PO*->new())">
- <advice aspect="TestAspect" name="otherAdvice"/>
- <advice aspect="TestAspect" name="advice"/>
- <interceptor-ref name="LastInterceptor"/>
- </bind>
-}}}
-
-The default ordering of these would create the following interceptor chain:
-{{{
- FirstInterceptor
- comes before
- SimpleInterceptor3
- comes before
- SimpleInterceptor2
- comes before
- SimpleInterceptor
- comes before
- TestAspect.otherAdvice
- comes before
- TestAspect.advice
- comes before
- LastInterceptor
-}}}
-
-!Precedence
-Now, imagine if the two pointcuts defined were more complex, so that some methods would resolve to the first, some to the second, some to both, and that we would
-like to be able to merge the interceptor chains according to a predefined order. This is where precedence comes in. It is defined in the jboss-aop.xml file as:
-
-{{{
- <precedence>
- <interceptor-ref name="SimpleInterceptor2"/>
- <advice aspect="TestAspect" name="advice"/>
- <interceptor-ref name="SimpleInterceptor3"/>
- <advice aspect="TestAspect" name="otherAdvice"/>
- </precedence>
-
- <precedence>
- <interceptor-ref name="SimpleInterceptor"/>
- <interceptor-ref name="SimpleInterceptor2"/>
- </precedence>
-}}}
-
-These two precedence entries each define a relative sorting order of interceptors. You can have as many precedence entries in your jboss-aop.xml file as you
-like, and as many entries as you would like in each. (Just make sure that the precedence orderings do not conflict.) The precedence entries are merged into an
-overall precedence entry, so that:
-
-{{{
- SimpleInterceptor
- comes before
- SimpleInterceptor2
- comes before
- TestAspect.advice
- comes before
- SimpleInterceptor3
- comes before
- TestAspect.otherAdvice
-}}}
-
-If you look at the first jboss-aop.xml snippet containing the bindings you will see that FirstInterceptor and LastInterceptor have not been defined to have a
-precedence. This means that they will remain where they were before any precedence was applied. Now if you run the example you should see that the advices
-are sorted and run according to the precedence defined.
-
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] <<< Entering FirstInterceptor type: POJO0OptimizedConstructorInvocation
- [java] <<< Entering SimpleInterceptor type: POJO0OptimizedConstructorInvocation
- [java] <<< Entering SimpleInterceptor2 type: POJO0OptimizedConstructorInvocation
- [java] <<< Entering TestAspect.advice type:POJO0OptimizedConstructorInvocation at 6e293a
- [java] <<< Entering SimpleInterceptor3 type: POJO0OptimizedConstructorInvocation
- [java] <<< Entering TestAspect.otherAdvice type:POJO0OptimizedConstructorInvocation at 6e293a
- [java] <<< Entering LastInterceptor type: POJO0OptimizedConstructorInvocation
- [java] empty constructor
- [java] >>> Leaving LastInterceptor
- [java] <<< Leaving TestAspect.otherAdvice type:POJO0OptimizedConstructorInvocation at 6e293a
- [java] >>> Leaving SimpleInterceptor3
- [java] <<< Leaving TestAspect.advice type:POJO0OptimizedConstructorInvocation at 6e293a
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] >>> Leaving FirstInterceptor
-}}}
-
-
Deleted: projects/aop/trunk/aop/docs/examples/stacks/stacks.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/stacks/stacks.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/stacks/stacks.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,31 +0,0 @@
-!!! Interceptor stacks
-
-You can declare predefined lists of interceptors can be referenced in any bindings.
-
-{{{
- <stack name="stuff">
- <interceptor class="SimpleInterceptor1"/>
- <interceptor class="SimpleInterceptor2"/>
- <interceptor class="SimpleInterceptor3"/>
- </stack>
-
- <bind pointcut="execution(* POJO->*(..))">
- <stack-ref name="stuff"/>
- </bind>
-}}}
-
-The <stack> element just defines a set of interceptors/advices. You can reference it from within a binding via a <stack-ref> element.
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] SimpleInterceptor1
- [java] SimpleInterceptor2
- [java] SimpleInterceptor3
- [java] someMethod()
-}}}
Deleted: projects/aop/trunk/aop/docs/examples/typedef/typedef.wiki
===================================================================
--- projects/aop/trunk/aop/docs/examples/typedef/typedef.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/examples/typedef/typedef.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,109 +0,0 @@
-!!! Typedefs
-
-If you have several classes that all are going to be intercepted in a similar way, you can declare a
-typedef to avoid declaring different pointcuts for each class. The typedef must resolve to a class
-expression.
-
-
-{{{
- <typedef name="TD" expr="(class(POJO) AND has(* *->method(..))) OR class($instanceof{ExecutionTypedefInterface}) OR class(@executionTypedef)" />
-}}}
-
-
-
-The typedef can then be used in place of the class name in pointcuts
-{{{
- <bind pointcut="execution($typedef{TD}->new())">
- <interceptor class="SimpleInterceptor" />
- </bind>
- <bind pointcut="execution(* $typedef{TD}->method())">
- <interceptor class="SimpleInterceptor" />
- </bind>
- <bind pointcut="field(* $typedef{TD}->field1)">
- <interceptor class="SimpleInterceptor" />
- </bind>
- <bind pointcut="all($typedef{TD})">
- <interceptor class="SimpleInterceptor2" />
- </bind>
-}}}
-
-In the supplied example POJO is not annotated and does not implement ExecutionTypedefInterface. POJO2 implements ExecutionTypedefInterface, and POJO3 is annotated with @executionTypedef.
-
-!Run the example
-To compile and run:
-{{{
- $ ant
-}}}
-It will javac the files and then run the AOPC precompiler to manipulate the bytecode, then finally run the example. The output should read as follows:
-{{{
-run:
- [java] --- new POJO(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.field1 = 10; ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- get pojo.field1;---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo.method(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
-
- [java] =======================
-
- [java] --- new POJO2(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo2.field1 = 10; ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- get pojo2.field1; ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo2.method(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
-
- [java] =======================
-
- [java] --- new POJO3(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo3.field1 = 10; ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- get pojo3.field1; ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
- [java] --- pojo3.method(); ---
- [java] <<< Entering SimpleInterceptor
- [java] <<< Entering SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor2
- [java] >>> Leaving SimpleInterceptor
-
-}}}
-
-POJO, POJO2 and POJO3 all get intercepted the same.
Deleted: projects/aop/trunk/aop/docs/index.wiki
===================================================================
--- projects/aop/trunk/aop/docs/index.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/index.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,17 +0,0 @@
-!!! JBossAOP Documentation
-
-This is documentation for the JBossAOP framework.
-
-* [Tutorial|examples/examples.html]
-* [Javadocs|api/index.html]
-* [Invocation Classes|misc/invocation.html]
-* [Non-Pointcutable things|misc/non_pointcutable.html]
-* [Running AOP Standalone|misc/standalone.html] (precompiler, classloader, etc.)
-* [Running within JBoss|misc/running_jboss.html]
-* [Annotation Compiler|misc/annotation_compiler.html]
-* [Debugging and Analysys Tools|misc/debugging_analysis.html]
-* [Calls to Reflection API|misc/reflection.html]
-
-Enjoy!
-
-
Deleted: projects/aop/trunk/aop/docs/misc/debugging_analysis.wiki
===================================================================
--- projects/aop/trunk/aop/docs/misc/debugging_analysis.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/misc/debugging_analysis.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,6 +0,0 @@
-!!!Debugging and analysis tools
-
-If you run AOP within the JBoss application server, you have access to our GUI management console that can show you a bunch of information about instrumented classes. You can access it at http://localhost:8080/web-console. In the AOP tree you can view all classes that have been loaded that pertain to AOP, what interceptors and advices that are attached, and also what metadata that has been attached. One particularly useful thing is the Unbounded Bindings folder. It specifys all bindings that are not bound. It allows you to debug when you might have a typo in one of your XML deployment descriptors.
-
-If you are not running within the management console, you can get the same information in an XML dump from a switch on the precompiler. Use the -report switch if running it on the command line , or specify report=true in the ANT task.
-
Deleted: projects/aop/trunk/aop/docs/misc/invocation.wiki
===================================================================
--- projects/aop/trunk/aop/docs/misc/invocation.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/misc/invocation.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,13 +0,0 @@
-!!!Invocation Object
-
-{{org.jboss.aop.Invocation}} is the base class for a bunch of different subtypes. Depending on the thing being invoked on a different Invocation object is created. All of the subclasses are in the org.jboss.aop package.
-
-|execution(method)|org.jboss.aop.joinpoint.MethodInvocation
-|get(field)|org.jboss.aop.joinpoint.FieldReadInvocation
-|set(field)|org.jboss.aop.joinpointFieldWriteInvocation
-|execution(constructor)|org.jboss.aop.joinpoint.ConstructorInvocation
-|call(method) AND withincode(method)|org.jboss.aop.joinpoint.MethodCalledByMethodInvocation
-|call(method) AND withincode(constructor)|org.jboss.aop.joinpoint.MethodCalledByConstructorInvocation
-|call(constructor) AND withincode(constructor)|org.jboss.aop.joinpoint.ConstructorCalledByConstructorInvocation
-|call(constructor) AND withincode(method)|org.jboss.aop.joinpoint.ConstructorCalledByMethodInvocation
-
Deleted: projects/aop/trunk/aop/docs/misc/joinpoint.wiki
===================================================================
--- projects/aop/trunk/aop/docs/misc/joinpoint.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/misc/joinpoint.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,16 +0,0 @@
-!!!JoinPoint Hierarchy
-
-{{org.jboss.aop.joinpoint.JoinpointInfo}} is the base interface for a bunch of different subtypes.
-Depending on the type of joinpoint being intercepted (only by before, after and after
-throwing advices), a different JoinpointInfo subinterface is provided. All of the
-subinterfaces are in the {{org.jboss.aop.joinpoint}} package.
-
-|execution(method)|org.jboss.aop.joinpoint.IMethodInfo
-|get(field)|org.jboss.aop.joinpoint.IFieldInfo
-|set(field)|org.jboss.aop.joinpoint.IFieldInfo
-|execution(constructor)|org.jboss.aop.joinpoint.IConstructorInfo
-|call(method) AND withincode(method)|org.jboss.aop.joinpoint.IMethodByMethodInfo
-|call(method) AND withincode(constructor)|org.jboss.aop.joinpoint.IMethodByConInfo
-|call(constructor) AND withincode(constructor)|org.jboss.aop.joinpoint.IConByConInfo
-|call(constructor) AND withincode(method)|org.jboss.aop.joinpoint.IConByMethodInfo
-
Deleted: projects/aop/trunk/aop/docs/misc/non_pointcutable.wiki
===================================================================
--- projects/aop/trunk/aop/docs/misc/non_pointcutable.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/misc/non_pointcutable.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,23 +0,0 @@
-!!!Non-pointcutable Classes, Fields, and Methods
-
-The following classes will be ignored for all matching pointcuts:
-
-* org.jboss.aop.*
-* org.jboss.util.*
-* javassist.*
-* All JBoss generated classes
-* All System classes
-
-The following field types will be ignored as well:
-
-* final
-* Field namess beginning with "_"
-* Field names containing a "$"
-* Fields added by AOP framework to a class
-
-The following method types are ignored:
-
-* Abstract
-* Native
-* Methods added by AOP framework
-* Methods beginning with "_"
Deleted: projects/aop/trunk/aop/docs/misc/reflection.wiki
===================================================================
--- projects/aop/trunk/aop/docs/misc/reflection.wiki 2007-05-07 21:19:13 UTC (rev 62848)
+++ projects/aop/trunk/aop/docs/misc/reflection.wiki 2007-05-07 21:27:26 UTC (rev 62849)
@@ -1,247 +0,0 @@
-!!! Reflection
-There are two issues with using the Reflection API with JBoss AOP
-
-#Aspects applied to constructors, fields and methods are bypassed
-#JBoss AOP adds a small amount of extra fields and methods
-
-As Java system classes in the java.lang.reflect package cannot be modified by JBoss AOP, the aspect org.jboss.aop.ReflectionAspect has been created to help with these issues. ReflectionAspect contains advices that can be bound with caller pointcuts where needed.
-
-!! Aspects applied to constructors and fields are bypassed
-The advice org.jboss.aop.ReflectionAspect will intercept your calls if you set up the caller pointcuts properly, and attach to any defined interceptor chains so that the same interceptions will occur as if accessing the field, or calling the method or constructor normally, i.e. without reflection. If you want to do something additional on interception, you can subclass it and override the methods: interceptConstructor(), interceptFieldRead(), interceptFieldWrite() and interceptMethod().
-
-An example subclass of ReflectionAspect:
-{{{
- package mypackage;
-
- import java.lang.reflect.Constructor;
- import java.lang.reflect.Field;
-
- import org.jboss.aop.joinpoint.Invocation;
- import org.jboss.aop.reflection.ReflectionAspect;
-
- public class MyReflectionAspect extends ReflectionAspect {
- protected Object interceptConstructor(
- Invocation invocation,
- Constructor constructor,
- Object[] args)
- throws Throwable {
- //Do your stuff
- return super.interceptConstructor(invocation, constructor, args);
- }
-
- protected Object interceptFieldRead(
- Invocation invocation,
- Field field,
- Object instance)
- throws Throwable {
- //Do your stuff
- return super.interceptFieldRead(invocation, field, instance);
- }
-
- protected Object interceptFieldWrite(
- Invocation invocation,
- Field field,
- Object instance,
- Object arg)
- throws Throwable {
- //Do your stuff
- return super.interceptFieldWrite(invocation, field, instance, arg);
- }
-
- protected Object interceptMethod(
- Invocation invocation,
- Method method,
- Object instance,
- Object[] args)
- throws Throwable {
- //Do your stuff
- return super.interceptFieldWrite(invocation, method, instance, arg);
- }
- }
-}}}
-As shown below, you will have information about what is being intercepted, so you could do your own filtering on what you do by configuring your aspect (by implementing XmlLoadable or using the javabean style configuration). The default behaviour of these methods is to mount the original interceptor chains.
-
-Declare the aspect example:
-{{{
- <aspect class="mypackage.MyReflectionAspect" scope="PER_VM"/>
-}}}
-
-__Intercepting Class.newInstance()__
-
-Bind the interceptNewInstance advice to Class.newInstance() calls:
-
-{{{
- <bind pointcut="call(* java.lang.Class->newInstance())">
- <advice name="interceptNewInstance" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Calls to Class.newInstance() will end up in MyReflectionAspect.interceptConstructor(), and the arguments are:
-
-invocation - The invocation driving the chain of advices.
-
-constructor - The constructor being called
-
-args - the arguments being passed in to the constructor (in this case a zero-length array since Class.newInstance() takes no parameters)
-
-Without the ReflectionAspect, interceptors bound to both constructor calls and execution will be ignored.
-
-__Constructor.newInstance()__
-
-Bind the interceptNewInstance advice to Constructor.newInstance() calls:
-
-{{{
- <bind pointcut="call(* java.lang.reflect.Constructor->newInstance())">
- <advice name="interceptNewInstance" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Calls to Constructor.newInstance() will end up in MyReflectionAspect.interceptConstructor(), and the arguments are:
-
-invocation - The invocation driving the chain of advices.
-
-constructor - The constructor being called
-
-args - the arguments being passed in to the constructor
-
-Without the ReflectionAspect, interceptors bound to both constructor calls and execution will be ignored.
-
-
-__Intercepting Field.getXXX()__
-
-Bind the interceptFieldGet advice to Field.get*() calls:
-
-{{{
- <bind pointcut="call(* java.lang.reflect.Field->get*(..))">
- <advice name="interceptFieldGet" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Calls to Field->getXXX() will end up in MyReflectionAspect.interceptFieldRead(), and the arguments are:
-
-invocation - The invocation driving the chain of advices.
-
-field - The field being read
-
-instance - the instance on which we are reading a field
-
-Without the ReflectionAspect, interceptors bound to field reads will be ignored.
-
-__Intercepting Field.setXXX()__
-
-Bind the interceptFieldGet advice to Field.set*() calls:
-
-{{{
- <bind pointcut="call(* java.lang.reflect.Field->set*(..))">
- <advice name="interceptFieldSet" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Calls to Field->getXXX() will end up in MyReflectionAspect.interceptFieldWrite(), and the arguments are:
-
-invocation - The invocation driving the chain of advices.
-
-field - The field being written
-
-instance - the instance on which we are writing a field
-
-arg - the value we are setting the field to
-
-Without the ReflectionAspect, interceptors bound to field writes will be ignored.
-
-
-__Intercepting Method.invoke()__
-
-Bind the interceptMethodInvoke advice to Field.set*() calls:
-
-{{{
- <bind pointcut="call(* java.lang.reflect.Method->invoke(java.lang.Object, java.lang.Object[]))">
- <advice name="interceptMethodInvoke" aspect="mypackage.MyReflectionAspect"/>
- </bind>
-}}}
-
-Calls to Method->invoke() will end up in MyReflectionAspect.interceptMethod(), and the arguments are:
-
-invocation - The invocation driving the chain of advices.
-
-method - The method being invoked
-
-instance - the instance on which we are invoking a method
-
-args - the arguments being passed in to the method
-
-Without the ReflectionAspect, interceptors bound to method calls will be ignored. Interceptors bound to
-method execution will however ALWAYS be invoked.
-
-
-
-!! Cleaning fields, interfaces and methods added to a class by JBoss AOP
-
-__Interfaces__
-
-JBoss AOP adds the org.jboss.aop.Advised interface to advised classes. If you intend to be calling Class.getInterfaces() on an advised class, you should bind the interceptGetInterfaces advice to Class.getInterfaces() calls:
-
-{{{
- <bind pointcut="call(* java.lang.Class->getInterfaces())">
- <advice name="interceptGetInterfaces" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Class.getInterfaces() will now return exactly the same as if the class had not been advised (i.e. the original class). This means org.jboss.aop.Advised is not in the list of interfaces returned.
-
-__Methods__
-
-JBoss AOP adds some methods, both public and private to advised classes.
-
-Bind the interceptGetMethod advice to Class.getMethod() calls:
-
-{{{
- <bind pointcut="call(* java.lang.Class->getMethod(..))">
- <advice name="interceptGetMethod" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Bind the interceptGetDeclaredMethod advice to Class.getMethod() calls:
-{{{
- <bind pointcut="call(* java.lang.Class->getDeclaredMethod(..))">
- <advice name="interceptGetDeclaredMethod" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Both the bindings above intercept the calls so that if you try to get any of the methods in the unadvised class the method is returned as normal. If you try to get one of the methods added by JBoss AOP, a NoSuchMethodException is thrown.
-
-The following advices remove the methods added by JBoss AOP and return the same methods as if the class was unadvised.
-
-Bind the interceptGetDeclaredMethods advice to Class.getDeclaredMethods() calls:
-{{{
- <bind pointcut="call(* java.lang.Class->getDeclaredMethods())">
- <advice name="interceptGetDeclaredMethods" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Bind the interceptGetMethods advice to Class.getDeclaredMethods() calls:
-{{{
- <bind pointcut="call(* java.lang.Class->getMethods())">
- <advice name="interceptGetMethods" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-
-__Fields__
-
-JBoss AOP adds only private fields to advised classes, no public ones, so we only need to intercept the "declared" versions of the get field methods i.e. Class.getDeclaredFields() and Class.getDeclaredField().
-
-
-Bind the interceptGetDeclaredFields advice to Class.getDeclaredFields() calls:
-{{{
- <bind pointcut="call(* java.lang.Class->getDeclaredFields())">
- <advice name="interceptGetDeclaredFields" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
-
-Bind the interceptGetDeclaredField advice to Class.getDeclaredField() calls:
-{{{
- <bind pointcut="call(* java.lang.Class->getDeclaredField(..))">
- <advice name="interceptGetDeclaredField" aspect="mypackage.MyReflectionAspect" />
- </bind>
-}}}
More information about the jboss-cvs-commits
mailing list