What are the key issues for commercial AOP use

What are the key issues for commercial AOP use
- how does AspectWerkz address them? Jonas Bonér Senior Software Engineer BEA Systems © The AspectWerkz Team 2004

I AspectWerkz overview
Outline I AspectWerkz overview what is AspectWerkz? how does it compare with AspectJ? II Design goals and decisions what are the key issues for commercial AOP? how does AspectWerkz solve them? III Conclusion future, links, questions This talk is divided in three parts: * In the first part I will start by giving you an overview of AspectWerkz. What it is, how it compares with AspectJ, what the syntax ,looks like etc. * In the second part I will outline some issues that we believe are key issues for commercial AOP and commercial adoption, and how AspectWerkz addresses these issues. *I will conclude the talk with a summary and a question session. © The AspectWerkz Team 2004

Outline I AspectWerkz overview what is AspectWerkz? how does it compare with AspectJ? II Design goals and decisions what are the key issues for commercial AOP? how does AspectWerkz solve them? III Conclusion future, links, questions © The AspectWerkz Team 2004

What is AspectWerkz? Dynamic AOP framework for Java
Open Source, founded Q4 2002 Sponsored by Tailored for dynamic AOP in real world applications JLS compatible Definition syntax in XML and/or Attributes Load time, runtime and static weaving Allows redefinition of aspects at runtime © The AspectWerkz Team 2004

Example using AspectJ aspect AsynchAspect {
private ThreadPool m_threadPool = ... Object around(): execution(void foo.bar.Baz.*(..)){ m_threadPool.execute(new Runnable() { public void run() { try { // proceed the execution in a new thread proceed(); } catch (Throwable e) { throw new WrappedRuntimeException(e); } }); return null; Since most of you are familiar with AspectJ, but not so many with AspectWerkz, I will start by giving you an example on how to implement an aspect in AspectJ and then show you how it can be done using AspectWerkz. This sample aspect turns regular synchronous method invocations into asynchronous invocations by proceeding the execution in a new thread. Let us now take a look at how this aspect can be implemented in AW. © The AspectWerkz Team 2004

The same example using AspectWerkz
class AsynchAspect extends Aspect { private ThreadPool m_threadPool = ... execution(void foo.bar.Baz.*(..)) */ Object execute(JoinPoint joinPoint) throws Throwable { m_threadPool.execute(new Runnable() { public void run() { try { // proceed the execution in a new thread joinPoint.proceed(); } catch (Throwable e) { throw new WrappedRuntimeException(e); } }); return null; Bind advice to pointcut As you can see there are many similarities in how the aspect is implemented. The main difference in the implementation is that in AW everything is pure Java. There is for example no ‘aspect’ keyword but the aspect is a regular Java class that inherits from the Aspect base class. The pointcuts are regular fields and the advice are regular methods. What differs is the definition. We can define our aspect using attributes or XML. [animate] * 3 As we can see here the attributes definition is based on JavaDoc tags. Why and how, I will explain later. © The AspectWerkz Team 2004

XML definition syntax <aspect class="samples.AsynchAspect"
deployment-model="perJVM"> <advice name="execute" type="around" bind-to="execution(void foo.bar.Baz.*(..))"/> </aspect> Deployment model Bind advice to pointcut We can choose to define the whole definition in XML. Using the aspect, pointcut and advice elements. [animate] You might wonder what the deployment model is. The deployment model defines the scope of the aspect, the life-cycle. Can be: perJVM, perClass, perInstance and perThread © The AspectWerkz Team 2004

One underlying model Runtime system Aspect model Join point model
Attribute definition XML definition Different views Aspect model One sole model Join point model Runtime system Static compilation Load time weaving Runtime weaving Different weaving schemes What is important to understand is that there is only one sole underlying model [animate] And that the two definition models are just different views of this underlying model. This sole model is then used by the different weaving schemes: Static weaving, load time weaving and runtime weaving. The runtime weaving arrow is a bit pale since we have it implemented, and it is working fine but it is not the ultimate solution, not pure runtime weaving. Will talk about that later © The AspectWerkz Team 2004

Outline I AspectWerkz overview what is AspectWerkz? how does it compare with AspectJ? II Design goals and decisions what are the key issues for commercial AOP? how does AspectWerkz solve them? III Conclusion future, links, questions, etc. So, after this crash course in AW I hope that you have at least a small idea what it is and what it can do. Let’s go on with the main section of this presentation and look at: What are the key issues for commercial AOP and commercial adoption. And. How does AW address these issues. © The AspectWerkz Team 2004

Design goals and decisions overview
JLS compatibility XML and Attribute definition Load time and Runtime weaving AspectJ’s join point/ pointcut model Dynamic runtime model Runtime compiler (JIT) Usability & Ease of adoption Integration Tool support Expressiveness & Orthogonality Performance vs. Dynamicity Enterprise application support Decisions Goals I want to talk about the design goals for AspectWerkz, and how they interact with the design decisions. (Of course that's crosscutting structure <grin>.) The goals on the vertical axis and the decisions on the horizontal. ...walk through the goals one by one and discuss the different design decisions made when trying to address them. © The AspectWerkz Team 2004

Design goals and decisions overview
JLS compatibility XML and Attribute definition Load time and Runtime weaving AspectJ’s join point/ pointcut model Dynamic runtime model Runtime compiler (JIT) Usability & Ease of adoption Integration Tool support Expressiveness & Orthogonality Performance vs. Dynamicity Enterprise application support Decisions Goals © The AspectWerkz Team 2004

Usability and Ease of adoption
JLS compatibility XML and Attribute definition Load time and Runtime weaving AspectJ’s join point/ pointcut model Dynamic runtime model Runtime compiler (JIT) Usability & Ease of adoption Integration Tool support Expressiveness & Orthogonality Performance vs. Dynamicity Enterprise application support Decisions Goals Usability and Ease of adoption © The AspectWerkz Team 2004

Design decisions JLS compatibility
Attribute definition (self-defined aspects) Metadata represented as attributes Currently custom JavaDoc tags are parsed and inserted in the compiled aspect .class file Ready for JSR-175 (attributes in Java 1.5) XML definition Definition of the aspect if no metadata used Reuse and refinement of the model if metadata used * One of AspectWerkz main design goals has been simplicity and ease of use. * The first design decision was that we wanted AW to be compatible with the Java language specification, meaning that all implementation of aspects, advice and introductions could be made in pure Java. * Second, we wanted the definition to be in a format that was intuitive to most users of Java and J2EE. So we settled for XML and attributes since both are widely used in the Java community. * In the first syntax, the metadata is represented as attributes Currently we are using a custom implementation since we don’t have attribute support in Java 1.3 and Java 1.4. These are parsed and inserted into the bytecode of the aspect class. Making the bytecode completely self-contained, containing both the implementation and the definition. This extra compilation step will not be needed in Java 1.5 when metadata annotations is part of the language. * The second syntax is XML based. It can be used as the only definition of the aspect, if no attributes are used. If attributes are used, then we can use it to reuse and refine of the model, override it or choose to “resolve the definition late” using XML. We can for example choose to define everything but the pointcuts in attributes and then later resolve the definition by defining the missing pointcuts in XML. This allows us to make decisions late in the development process, at deployment time etc. © The AspectWerkz Team 2004

Advantages Pure Java and XML is intuitive to users of Java and J2EE
Integrates well in any IDE source parse Works well with any testing framework and refactoring tool AspectWerkz stays “out of the way” Allows decoupling of pointcuts and advice Some decisions can be taken at deployment time We have experienced that the JLS compatibility approach together with a definition syntax based on XML or attributes is found intuitive to most users of J2EE. Integrates well into any: IDE source parser, existing test framework and any standard refactoring tool. This is for example the reason why the next version of Cactus, which is one of the leading testing frameworks for J2EE, will be based on AspectWerkz and not AspectJ. You can say that AspectWerkz is stays out of the way, as long as the developer wants it to I might add. You as developer can code just as usual in your favorite IDE. Without immediate needs for custom plugins and specific tool support. We believe that this will ease the adoption. This also allows loose coupling between advice and pointcuts. This is important when dealing with aspect reuse. In AspectWerkz you have the option of either: * Using inheritance: meaning defining the advice in an abstract base aspect and the pointcuts in a concrete subaspect * Or define the pointcuts in an external XML file which allows you to make the decision of to which pointcut you want to bind to which advice at deployment time and not at compile time. © The AspectWerkz Team 2004

Less elegant and concise syntax compared to a language extension
Disadvantages Less elegant and concise syntax compared to a language extension © The AspectWerkz Team 2004

Why two definition models?
Which to prefer? Complements each other Good in different contexts and situations © The AspectWerkz Team 2004

XML definition Advantages Drawbacks
No post compilation for metadata management Loosely coupled Drawbacks Separates the implementation from the definition Can make the application harder to maintain refactor © The AspectWerkz Team 2004

Attribute definition Advantages Drawbacks
Aspects are self-defined and self-contained Both implementation and definition in the same single class Easy to build reusable aspect libraries Drawbacks Requires an additional compilation step (not in Java 1.5 and above) Stronger coupling © The AspectWerkz Team 2004

Conclusions Both AspectWerkz’s approach and AspectJ’s language extension introduces a new language Hard to keep the model orthogonal, extensible and expressive but yet simple and easy to understand Early versions with advice modeled after the command pattern did not scale at all For example a single aspect could consist of five classes and a XML definition file We believe that both AspectWerkz's approach and AspectJ's language exension introduces a new language. Both approaches has its own drawbacks and advantages. Which approach you prefer depends on background, context etc. It was hard to come up with a definition model that was orthogonal, extensible and expressive but yet simple and easy to understand. It went through many iterations with help from both users and experts. I have to stress that this was in the early versions. In the latest implementation AspectWerkz has adopted almost the full AspectJ model which is both orthogonal, expressive and extensible. Advice where in the first versions modeled after the command pattern, meaning that they had to be implemented as separate classes. This did not scale at all. One simple aspect could consist of 5 classes + a definition file. This was solved by impl. the aspect as a regular Java class and let the methods be the advices etc. Then the definition could be impl. using attributes on the methods allowing the user to have both the impl. and the definition in one single Java file (.class file). So what originally needed six files can now be implemented in one single file. © The AspectWerkz Team 2004

Integration Decisions Goals JLS compatibility
XML and Attribute definition Load time and Runtime weaving AspectJ’s join point/ pointcut model Dynamic runtime model Runtime compiler (JIT) Usability & Ease of adoption Integration Tool support Expressiveness & Orthogonality Performance vs. Dynamicity Enterprise application support Decisions Goals Integration © The AspectWerkz Team 2004

Target problem Using a custom class loader has problems (JBoss, weblogic-aspects and cglib etc.): All classes needs to be loaded using this custom loader Can not transform classes loaded by any other loader AspectWerkz’s solution: Provides a JVM wide hook mechanism Controls all class loading in the JVM Platform and vendor independent Tested and verified on: WebLogic, JBoss, Tomcat, WebSphere, IBM JRE, BEA JRockit, Sun HotSpot, Java 1.3, 1.4 The simplest way of enabling load time weaving is to use a custom classloader. However this approach has many problems. * All classes needs to be loaded by this class loader * Can not transform classes loaded by any other class loader This will make it impossible to work properly in for example application servers with their complex class loading hierachies [animate] AW solves this by providing a so-called ‘JVM wide hook mechanism’ that controls all classloading the JVM. * This allows it to work fine in application server environments. * This also means that the weaving mechanism is vendor and platform independent. * Has been tested and verified to work well on all major application servers and JVM implementations. © The AspectWerkz Team 2004

Load time weaving JDI and HotSwap
Using classloader patching Requires the –Xdebug flag (debug mode) JRockit MAPI’s class redefinition capabilities No classloader patching or -Xdebug flag JVMTI (JSR-163) in Java 1.5 Will standardize class redefinition in Java No classloader patching or –Xdebug flag AW has different ways of enabling load time weaving. We are using JDI and HotSwap, the Java debug API In this approach we use CL patching. I will show you an illustration of that later. We have generalized an idea pioneered by JMangler. The problem with this approach, requires the JVM to be started in debug mode, which is a bit slower than regular execution We also use the JRockit MAPI class redefinition capabilities * NO classloader magic, NO -Xdebug In Java 1.5 we will make use of JVMTI (JSR-163), * NO classloader magic, NO –Xdebug * Will STANDARDIZE class redefinition * NO class loader magic needed. © The AspectWerkz Team 2004

Runtime weaving Problem: some weaving operations requires schema changes Our current solution: “Two phase weaving” First phase: Classes are first prepared at load time (tiny) Second phase: Classes can then be woven at any point “In-process HotSwap” No JDWP and startup JVM needed “Multi weaving” Classes can be woven, rewoven or unwoven at any point In this implementation we are using HotSwap and JDI (in 1.4) or JVMTI (in Java 1.5) to weave the classes at any point at runtime. The problem is that some weaving operations requires schema changes (fields, methods, interfaces etc.) This is solved by “two-phase weaving” where we prepare all classes when they are loaded (or in a post-compilation step). This phase is minimal and fast. When we have this in place it is trivial to do * multiple, runtime weaving * and allowing the class to return to its original state at any point in the lifecycle of the application. The implementation uses an "in-process" approach which means * no JDWP and startup JVM etc. * but everything is handled within the same JVM © The AspectWerkz Team 2004

Zero overhead at runtime (for non-woven or unwoven methods)
Runtime weaving Zero overhead at runtime (for non-woven or unwoven methods) The original bytecode is guaranteed to run (for non-woven or unwoven methods) This means that we will have * zero overhead for the methods that are not weaved but still allow us to do runtime weaving at any time * The original bytecode is guaranteed to run © The AspectWerkz Team 2004

Conclusions The JVM wide hook mechanism makes it possible for the framework to work correct in complex class loader hierarchies (application servers etc.) We believe that load time and runtime bytecode weaving makes the integration more transparent than a static compilation process The JVM wide hook mechanism makes it possible for the framework to work correct in complex class loader hierarchies like in application servers etc. We believe that load time and runtime bytecode weaving makes the integration more transparent than a static compilation process. The user can just define his aspects package them and deploy and the weaving takes place "under the hood". © The AspectWerkz Team 2004

Disadvantages Slows down startup time:
The startup process does not scale well in certain situations This problem will somehow be addressed with: JVMTI => No -Xdebug flag needed JRockit MAPI => No -Xdebug (Java 1.3 and 1.4) Port to ASM bytecode library (>700% percent faster than BCEL/Javassist) Optimizations (like parsing the constant pool to allow early filtering of classes) Native JVM support There is however some disadvantages. The startup process does not scale well in certain situations, for example if you define your pointcuts very freely and/or have a huge codebase to instrument. This problem will somehow be addressed with: * JVMTI, no -Xdebug * JRockit MAPI, no -Xdebug * Port to ASM bytecode kit, 1000% percent faster than BCEL/javassist etc. * Other optimizations, like parsing the constant pool to do early filtering of classes * Native JVM support © The AspectWerkz Team 2004

Tool support Decisions Goals JLS compatibility
XML and Attribute definition Load time and Runtime weaving AspectJ’s join point/ pointcut model Dynamic runtime model Runtime compiler (JIT) Usability & Ease of adoption Integration Tool support Expressiveness & Orthogonality Performance vs. Dynamicity Enterprise application support Decisions Goals Tool support © The AspectWerkz Team 2004

Tool support AspectWerkz is currently lacking good tool support apart from: Plugin for the build system Support for debugging aspects within an IDE JUnit (unit testing framework) extension The standardization of attributes in JSR-175 will bring many tools for working with metadata We believe that good tool support will become a crucial factor for mass adoption AspectWerkz is currently lacking good tool support. The tool support we have is: * Plugin for the Maven build system * Support for debugging application and aspects within a regular debugger/IDE * Extension to the JUnit unit testing framework With Java 1.5 and the standardization of attributes through JSR-175 we will most likely have many tools for managing and working with metadata through attributes, the IDEs will support it etc. This will be a great fit to the metadata driven AOP in AspectWerkz. We believe that good tool support will become a crucial factor for mass adoption. Both standard development tools like debuggers, code browsers, testing and refactoring tools as well as more sophisticated tools to help us manage aspect complexity in all phases in the development process. © The AspectWerkz Team 2004

Expressiveness and Orthogonality
JLS compatibility XML and Attribute definition Load time and Runtime weaving AspectJ’s join point/ pointcut model Dynamic runtime model Runtime compiler (JIT) Usability & Ease of adoption Integration Tool support Expressiveness & Orthogonality Performance vs. Dynamicity Enterprise application support Decisions Goals Expressiveness and Orthogonality © The AspectWerkz Team 2004

Join point and pointcut model
Regular expression based pointcut language, largely inspired by AspectJ Join point model largely inspired by AspectJ Supported join points: method (static and member) and constructor execution method (static and member) and constructor call field (static and member) modification and access catch clauses cflow Supports pointcut composition Supported advice: around, before and after I would say that no AOP framework is more powerful than its join point model is expressive. AW has a regular expression based pointcut language that is largely inspired by AspectJ. The join point we currently support are: One thing that we have found crucial is the ability to compose pointcuts, to form expressions out of pointcuts. We also support around, before and after advice. © The AspectWerkz Team 2004

Orthogonality Orthogonality is:
crucial for the model to scale (with the needs of the application) needed for the model to be intuitive and predictable In the latest version we have reached a high level of orthogonality: All advice types works with all pointcut designators Pointcut composition allows combinations of all types of pointcuts We believe that keeping the model orthogonal is both: * crucial for the model to scale with the needs of the application and * needed for the model to be intuitive, predictable, to follow the rule of least surprise In the latest version of AW we have reached a high level of orthogonality: * All advice types works with all pointcut designators (except for the handler pointcut which is only possible to bind to the before advice) * pointcut composition allows combinations of all types of pointcuts © The AspectWerkz Team 2004

Definition constructs
Definition constructs in AspectJ: join points pointcuts advice implementation AspectWerkz introduces a new construct the binding from pointcuts to advice implementation Allows AspectWerkz to have named advice Useful in dynamic AOP as a handle to the advice One difference compared to AspectJ is that AspectJ has three definition constructs: join points, pointcuts and the advice implementation While AW introduces a new construct: the binding from pointcuts to advice implementation This allows AW to have named advice, which is very useful in for example dynamic AOP since it give you a handle to the advice © The AspectWerkz Team 2004

Current limitations Does not support all the dynamic and static pointcut designators as AspectJ We currently do not support: cflowbelow (in development) within (in development) args (planned) target (planned) static initialization (planned) pre initialization if Does not support all the dynamic and static pointcut designators as AspectJ We currently do not support: * cflowbelow (in development) * within (in development) * args (planned) * target (planned) * static initialization (planned) * pre initialization © The AspectWerkz Team 2004

Performance vs. Dynamicity
JLS compatibility XML and Attribute definition Load time and Runtime weaving AspectJ’s join point/ pointcut model Dynamic runtime model Runtime compiler (JIT) Usability & Ease of adoption Integration Tool support Expressiveness & Orthogonality Performance vs. Dynamicity Enterprise application support Decisions Goals Performance vs. Dynamicity © The AspectWerkz Team 2004

Design decisions Dynamic runtime model Runtime (Just-In-Time) Compiler
Allows redefinition of the system at runtime Introduces a layer of indirection, loose coupling Makes use of delegation and reflection Runtime (Just-In-Time) Compiler Similar to JIT compilers in modern JVMs Detects advice chains that are often executed and compiles a custom class on the fly that invokes the advice chain and the target join point statically Aware of redefinitions of the runtime model Makes heavy use of caching and lazy loading to improve runtime performance AspectWerkz is designed to have a dynamic runtime model, which means that the user can redefine his aspect system at runtime. To support a dynamic runtime model the framework is making use of delegation and reflection and introduces a level of indirection to allow the aspects and target classes to be loosely coupled. We have recently implemented a runtime compiler, which has similarities with Just-In-Time compilers in modern JVMs, that detects advice chains that are often executed and creates a custom class on the fly that invokes the advice chain and the target method statically. These custom classes are cached and aware of redefinitions of the runtime model. AspectWerkz makes heavy use of caching and lazy loading to improve the runtime performance © The AspectWerkz Team 2004

Advantages The dynamic runtime model allows
addition of advice removal of advice reordering of advice swapping of introduced implementations at runtime with almost zero overhead The dynamic compiler allows us to have the “best of both worlds” Performance closer to a statically compiled approach The advantage of a dynamic runtime model The dynamic runtime model allows: * addition of advices * removal of advices * reordering of advices * swapping of introduced implementations at runtime with almost zero overhead The dynamic compiler allows us to have the “best of both worlds”: * Performance closer to a statically compiled approach * The advantage of a dynamic runtime model © The AspectWerkz Team 2004

Simple benchmark The overhead of five around advice applied to a method call join point AspectJ ms/call AspectWerkz 0.10 RC ms/call JBoss AOP 1.0Beta ms/call Configuration: Hardware: Intel Pentium 4 Mobile 1.6 MHz JVM: HotSpot 1.4.2_01 OS: Windows XP As we can see here using JIT optimization * We are around 60 % faster than JBoss new release * While AspectJ is still around 60 % faster. An interesting note might be that: * The AW is using HotSwap and is running in debug mode in this bench © The AspectWerkz Team 2004

Limitations Hard to match the speed of statically compiled systems (AspectJ etc.) since: We have to keep track of join point state: Need to handle the state management Need to know if a join point is redefined and has become “dirty” (and the JIT compiled class is “stale”) Need a level of indirection Can not add new pointcuts to the system without: Reloading of the classes Inserting traps at all potential points in the system Runtime weaving is needed One limitation is that it is not possible to add new pointcuts to the system without: * Reloading of the classes, which is not a practical * Preparing all points in the system that we might want to instrument later (like JBoss and JASCO) * Runtime weaving support. The runtime weaving support in AW requires that you add wrapper methods to all execution points. But all other join points can be weaved without any preparations. Hard to match the speed of statically compiled systems like AspectJ since: We have to keep track of join point state: need to know if a join point is redefined and has become “dirty” (and the JIT compiled class is “stale”) * Need a level of indirection * Need to handle the state management © The AspectWerkz Team 2004

Enterprise application support
JLS compatibility XML and Attribute definition Load time and Runtime weaving AspectJ’s join point/ pointcut model Dynamic runtime model Runtime compiler (JIT) Usability & Ease of adoption Integration Tool support Expressiveness & Orthogonality Performance vs. Dynamicity Enterprise application support Decisions Goals Enterprise application support © The AspectWerkz Team 2004

Requirements for Enterprise AOP
Security Isolation Visibility Runtime management Deployment modules Needs to be handled both: Horizontally – within one single class loader Vertically – following a class loader hierarchy Aspect Container The Aspect Container is a concept that brings together many important concerns that are crucial for AOP to work practically in real-world applications. It deals with problems that occurs when many dynamic aspect system co-exist within the same application server/JVM. It handles issues like security, isolation, visibility, deployment and runtime management. These issues that needs to work both vertically, meaning follow the class loader hierarchy, as well as horizontally, meaning within one class loader. The Aspect Container is not tied to either runtime weaving, load time weaving or post-process weaving but is an architectural concept. © The AspectWerkz Team 2004

Aspect Container We have a problem when multiple dynamic aspect systems are deployed in the same JVM Need a way to allow them to co-exist and interact in a well-defined, organized, layered way A class is transformed according to the definitions of all aspect systems that is visible from its defining class loader Security, visibility and isolation needs to follow the same scheme To be implemented The current AspectWerkz implementation supports a single Aspect system. We think there is a huge need to be able to support several dynamic Aspect systems in a well organized layered way. The main concept is aspect/class loader interaction. For example: * An aspect deployed at system class path level should impact all classes in the JVM, that has a matching pointcut * While an aspect deployed in a web application should impact only the web application itself. Key issue: This means that a class is transformed according to all Aspect systems that is visible from its defining class loader. When we have this in place, more advanced architectural concepts can be defined and implemented, like: security, visibility, isolation rules as regards dynamic AOP features, activation and deactivation of a whole aspect system at runtime, deployment rules, runtime management etc. The role of the Aspect Container is to manage all these things. The Aspect Container has only to some extent been prototyped in AspectWerkz. We expect to have implemented and production ready by the end of the year. © The AspectWerkz Team 2004

Outline I AspectWerkz overview what is AspectWerkz? how does it compare with AspectJ? II Design goals and decisions what are the key issues for commercial AOP? how does AspectWerkz solve them? III Conclusion future, links, questions © The AspectWerkz Team 2004

Native JVM support for AOP
Future work Native JVM support for AOP JRockit JVM 1.5 Java 1.5 support for generics and attributes Weaving based on JVMTI Metadata driven AOP Tool support Aspect Container © The AspectWerkz Team 2004

Where can I find more information?
Documentation Technical papers Articles Weblog articles © The AspectWerkz Team 2004

Example of use-cases Very useful in enterprise application environments Weave third party libraries without having post process all the jars For example when advising on an interface, e.g. java.sql.PreparedStatement+.execute() Sometimes the decision to apply an aspect can not be taken at build time but at: Deployment time, perhaps much later and by another person Runtime (runtime diagnostics, profiling, performance optimizations etc.) Load and runtime weaving has proved itself to be very useful in enterprise application environments. For example you can weave third party libraries without having post process all the jars. Sometimes libraries are loaded and replaced at runtime and using load time weaving, this is something you do not have to care about. You might not know in which library a certain class resides: for example when instrumenting on an interface, e.g. 'java.sql.PreparedStatement+.execute()'. Sometimes the decision to weave a class can not be taken at build time but at: * deployment time, perhaps much later and by another person * or at runtime, for example runtime diagnostics, profiling, performance optimizations etc. © The AspectWerkz Team 2004

Some extra effort needed to deal with
Lessons learned Some extra effort needed to deal with differences in application server implementations (class loading schemes etc.) differences in JVM implementations (IBM JRE) We had problems with thread safety in the transformation process Issues with bugs in bytecode libraries Since class loading is complex and and often implemented very differently in different application servers it took a while for us to reach a stable implementation for the load time weaving. Since some JVM implementation details differ, we had to put some effort into finding an implementation that worked equally good on all of them and in some rare cases have conditional code for different JVMs. We had problems with the bugs in the bytecode libraries, especially when dealing with thread safety. © The AspectWerkz Team 2004

Loose coupling using delegation
caller instance perJVM object.myMethod() BeforeAdvice1 AfterAdvice1 BeforeAdvice2 AfterAdvice2 perClass callee instance perInstance Join Point This slide will try to illustration how the loosely coupled runtime model works. 1. We have one caller object invoking a method in a callee object. 2. We have four different life-cycle containers. PerJVM, PerClass, PerInstance and PerThread. 3. That the advice can live in. 4. The JoinPoint instance reads in the advice info at class load time. [run the animation to end] Join Point is aware of state: * If the JIT compilation class is stale * Redefinition of the join point (add/remove/reorder advices) * Removal of aspects etc. If optimization is turned on, this Join Point instance can be replaced by a dynamically created class that will invoke the advice chain and the target method statically. perThread public void myMethod() { ... } © The AspectWerkz Team 2004

What are the key issues for commercial AOP use

Similar presentations

Presentation on theme: "What are the key issues for commercial AOP use"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

What are the key issues for commercial AOP use

Similar presentations

Presentation on theme: "What are the key issues for commercial AOP use"— Presentation transcript:

Similar presentations

About project

Feedback