2. AspectWerkz Plain Java AOP Presented by: Gal Ostfeld January, 2005 Technion, Israel

3. Trivia Founded Q4 / 2002 Founders: –Jonas Boner, senior software engineer at BEA –Alexandre Vasseur, software engineer at BEA Open source, by “codehaus” project Sponsored by BEA

4. Presale… AspectWerkz is a simple, high-performant, dynamic, lightweight and powerful AOP for Java AspectWerkz offers both power and simplicity and will help you to easily integrate AOP in both new and existing projects AspectWerkz is a Java only solution that integrates smoothly into current development processes, IDEs, tools etc. without extending Java language AspectWerkz has been designed to have an extensible AOP aspect container where any kind of aspects can coexist, such as: AspectJ, AOP Alliance, Spring etc.

5. Diving in – “Hello World!” package testAOP; public class HelloWorld { public static void main(String args[]) { HelloWorld world = new HelloWorld(); System.out.println(world.greet()); } public String greet() { return "Hello World!"; }

6. 1.Aspect methods need to take the JoinPoint argument otherwise the AspectWerkz weaver won't be able to identify the method when the aspect is weaved in 2.JoinPoint contains metadata & RTTI of this join point 3.In AspectWerkz 2.0 StaticJoinPoint can be used when RTTI access isn’t needed, thus optimizing performance Now we write the aspect code package testAOP; import org.codehaus.aspectwerkz.joinpoint.JoinPoint; public class MyAspect { public void beforeGreeting(JoinPoint joinPoint) { System.out.println("before greeting..."); } public void afterGreeting(JoinPoint joinPoint) { System.out.println("after greeting..."); }

7. Aspect class requirements Any Java class can be an aspect providing… –The class must be public –The method implementing the advice must be public –There must be one of these two c’tor-s defined: An implicit/explicit default (no-arg) c’tor A c’tor taking an AspectContext instance as its only param (enables to retrieve info about the runtime system, access deployment time param-s, access meta-data etc.) AspectWerkz call order If no c’tor is found - an exception is thrown

8. Specifying pointcuts and advice methods At this point we have the test application and the actual aspect code We still need to tell AspectWerkz where to insert the aspect methods (“pointcuts”), and which aspect method to actually insert (“advice”) Specifying pointcuts and advice can be done using either of (or a mixture of), the following methods…

9. Supports late (deployment time) binding Loose coupling – code reuse Aspect class name holding advices The pointcut name is only used to bind the advice Method #1: XML definition file The name of the method implementing the advice before/after/aroun d Wildcards Output: before greeting... Hello World! after greeting...

10. It is refactoring/tool friendly Call joinPoint.proceed() to invoke the next advice in the chain (or the target method if there are no more advices) which will return the result from the next advice in the chain (or the target method) Definition is strong coupled to this app Adding metadata to actual aspect class – self contained & self defined aspect Method #2: Annotations In Java 1.3/1.4, annotations are defined in JavaDoc style (In Java 1.5, Java annotations are used) package testAOP; import org.codehaus.aspectwerkz.joinpoint.JoinPoint; public class MyAspectWithAnnotations { /** * @Around execution(* testAOP.HelloWorld.greet(..)) */ public Object yeller(JoinPoint joinPoint) { Object greeting = joinPoint.proceed(); return " " + greeting + " "; }

11. You still have to create a tiny XML 'stub' which tells the AspectWerkz runtime system which Java classes it should load and treat as aspects Method #2: Annotations (cont.) First you need to compile your aspect class files. Then run a special AspectWerkz tool known as the AnnotationC compiler (unless you use Java 5’s annotations) Output: Hello World! Combining XML and annotations can still make the code reusable – though less tool friendly

12. 1.Performing the weaving is done by using the AspectWerkz tool to run java with the relevant classes, pointing it to the definition XML file/stub 2.Doesn't modify any of the application classes 3.Hot deployment and undeployment of aspects Weaving in and running aspects 1.Amends your actual application classes definition 2.Running the aspect is just a matter of invoking the main class 3.Statically compiled code can be highly tuned There are two kinds of ways to actually weave the code together: –Online weaving Performs weaving as classes are loaded into the JVM –Offline weaving Done before the code is actually run In both cases you need AspectWerkz jar-s on your classpath and you need to provide an XML definition file/stub

13. Weaving schemes AspectWerkz offers three weaving schemes: 1.Post compilation of the application: offline weaving at application build time 2.Class load time weaving: online weaving at application deployment time 3.Runtime weaving: online weaving in a running application

14. Online weaving – how is it done? Java 5 - The AspectWerkz weaver is embedded as a Java standardized preMain agent in the JVM and thus activated transparently before any call to the main method HotSwap (Java 1.4) - A 1 st tiny JVM launches your target application in a 2 nd JVM. The 1 st JVM hooks AspectWerkz in the 2 nd before the main class + dependencies gets loaded Bootclasspath (Java 1.3) - Putting an enhanced class loader in the JVM bootclasspath BEA JRockit - The AspectWerkz weaver is embedded as a ClassPreProcessor (native mechanism) component in the JRockit JVM

15. This is useful only for aspects that have XML definitions - they can have annotations as well, if so then the XML definition will override the annotation definition Hot deployment DeploymentHandle- s can be used for undeployment - they allow you to undeploy the aspect you deployed and be sure that it will be undeployed exactly the way it was deployed DeploymentHandle deploy ( Class aspect, String xmlDef, DeploymentScope scope, ClassLoader deployLoader )

16. Hot undeployment void undeploy(Class aspect) void undeploy(Class aspect, ClassLoader loader) void undeploy(DeploymentHandle deploymentHandle) DeploymentHandle is used to revert to the state before that deployment event defined by the handle occurred All join points that were affected by a deployment event will be reverted to the state they were in before the deployment occurred. This means that we need to keep track of order and dependencies

17. Deployment scope It’s a special kind of pointcut which will prepare the application and advise the points that we’re interested in doing hot deployment on later We can then retrieve a handle to this deployment scope and be sure that our aspect will be deployed at valid points in our code that suit us DeploymentScope scope = SystemDefinition.getDefinitionFor(loader, systemId).getDeploymentScope("toString " );

18. Pointcut language (some more presale) AspectWerkz supports a fine- grained pattern language for picking out pointcuts

19. Pointcut language - wildcards You can utilize three types of wildcards when Constructing your patterns: “*” - Is used as a regular wildcard. Matches for example only one package level or one method parameter “..” - Two uses: 1.To match any sequence of characters that start and end with a "." (so it can be used to pick out all types in any sub-package) 2.In method selectors, to match as many parameters as possible “+” - Is used to pick out all subtypes of a type (including the type itself)

20. Pointcut language – pointcut composition To compose pointcut expressions you can use the following logical operators: ! - logical not || or OR - logical or && or AND - logical and () - for grouping

21. Pointcut language – class selection !private com.*.Stam* public static com.pack.Stam private com.package.Stam2 com.company.sub.Stam3

22. Pointcut language – method selection int method(*,java.lang.*,Number+) int method(int i, String s, Long l) int method(int i1, int i2, Long l) int method(int i, Long l) Java.lang.* me*o*(int,..) StringBuffer method(int i) String meo(int i, String s, Object o) int method(int i, double d).

23. Pointcut language – field selection java.lang.* *_* StringBuffer m_ int s_inputString String _

24. Pointcut language – pointcut types execution() – method or c’tor execution call() – method or c’tor call set() - field modification get() – field access handler() – (before) catch clause within() - picks out a type set withincode() - picks out a method or c’tor set hasmethod() - picks out a class that has a method or c’tor matching a given pattern hasfield() - picks out a class that has a field matching a given pattern args() - filter method or c'tor param-s and field types and retrieving and keeping references to them. this()/target() - narrow a pointcut expression based on caller/callee types or gain access to them in the advice cflow() - defining a control flow

25. Pointcut references – code reuse Pointcuts defined in one aspect can be referred in another aspect definition. This can be very useful when building up pointcut libraries that need to be used throughout a project or multiple projects.

26. There’s an option of passing parameters to aspects This can be very convenient in order to reuse the same aspect but with a different configuration To pass a parameter to the aspect add a param tag to the aspect definition: To get the parameter (from within an aspect) use the AspectContext.getParameter(String paramName) method to retrieve the parameter value (as a String) To set a new (or override) a parameter (from within an aspect) use the AspectContext.setParameter(String paramName, String paramValue) method Passing parameters to aspects

27. Deployment models AspectWerkz supports four different deployment models, which define the scope of the Aspect: 1.perJVM - one instance per JVM 2.perClass - one instance per class 3.perInstance - one instance per instance 4.perThread – one instance per thread

28. Extensible aspect container architecture - background In recent years the Java AOP landscape has become filled with a whole bunch of frameworks, each one with its own way of defining and instantiating its aspects and with its own weaver, runtime environment and tools This isn’t making it easier for new users of AOP and doesn’t speed up its adoption Most existing frameworks have a lot in common

29. Extensible aspect container architecture - outcome The above situation encouraged AspectWerkz designers to design an open architecture that allows you to plug in extensions that can handle the framework specific details, while the common things are shared AspectWerkz architecture holds a weaver and a container that can weave, deploy and run any aspect no matter how it is implemented and defined Thus there’s a basis for standardization on tools (development and runtime manageability)

30. Extensible aspect container architecture - example Let’s illustrate what happens when a method has been advised by a “before” advice on “execution” (callee) side: time unadvised application

31. Extensible aspect container architecture – conclusions The diagram will be the same no matter how the advice has been implemented There are parts (like "how to get the advised member arguments?" ) that are independent of the implementation details of the aspect and thus can be solved in the same way no matter what framework we would use (→part of the aspect container) Other parts (like "how to get an aspect instance?“) that are framework specific (→part of the extension implementation)

32. Aspects belonging to different aspect models Each extension is seen as an aspect model and is implemented by implementing the AspectModel interface Aspects from different aspect models can coexist in one single runtime environment Extensible aspect container architecture - illustration AspectWerkz 2.0 modules

33. AspectWerkz custom extensions If you want to plug in your own AOP framework into the AspectWerkz Extensible Container then: 1.Implement the AspectModel interface public interface AspectModel { String getAspectModelType(); boolean requiresReflectiveInfo(); AroundClosureClassInfo getAroundClosureClassInfo(); void defineAspect(..); void createMandatoryMethods(..); void createInvocationOfAroundClosureSuperClass(..); void createAspectReferenceField(..); void createAspectInstantiation(..); void createAroundAdviceArgumentHandling(..); void createBeforeAdviceArgumentHandling(..); void createAfterAdviceArgumentHandling(..); } 2.Register your extension and the container will manage the weaving, deployment, life-cycle management etc.

34. AspectWerkz the next generation AspectWerkz intends to have one single aspect container and internal representation but make the weaver pluggable, so that different strategies of doing the actual weaving could be plugged in

35. All advices did the same amount of work The numbers in the table show how many nanosec-s per iteration, where an iteration is the invocation of the advice and the advised method “after” advices produced identical results as “before” advices The best performance (of advised invocation) per advice type is colored green Benchmark

36. Benchmark results analysis The Spring extension was as expected much faster than the Spring system since it enjoyed the optimization benefits of static compilation AspectJ, AspectJ extension and AspectWerkz were pretty similar in the “before” (and “after”) advices The “around” advices’ landslide of AspectJ over AspectJ extension and AspectWerkz is explained by the AspectJ compiler inlining the advice body in the target class

37. News flash: Last minute update… In the last few days the AspectWerkz site has released the following statement: “The AspectJ and AspectWerkz projects have agreed to work together as one team to produce a single aspect-oriented programming platform building on their complementary strengths and expertise…”

38. News flash: Last minute update…(cont) “The combined strengths of the two teams will enable us to deliver a more comprehensive technology suite more quickly than either team could alone. The backing of two major vendors (IBM and BEA) and a large open source community will accelerate the adoption of AOP in the enterprise…”

39. “This will begin with an extension to the AspectJ language to support an annotation-based style of development, and with tighter integration of load-time weaving for AspectJ in the J2EE environment… AspectJ 5 will also have extended deployment options for load-time weaving, supporting aop.xml deployment files in the style of AspectWerkz.” News flash: Last minute update…(cont)

40. Summary Powerful, expressive and simple AOP framework JLS compatible (does not extend Java) Definition syntax in XML or annotations (or JavaDoc style annotations) Build time/Load time/Run time weaving Hot Deployment and Undeployment High performance Tailored for dynamic and static AOP in real world applications Infrastructure extendable to be compatible with other AOP frameworks