Ramnivas Laddad on Making AOP Choices With AspectJ and Spring AOP
Spring AOP/AspectJ combination offers many choices, whether they are AOP system related (bytecode-based or proxy-based AOP), syntax related (traditional AspectJ, @AspectJ, or XML syntax) or weaving options (build time or load-time weaver), and a clear understanding of all those choices is very important to apply them pragmatically when using Aspects in enterprise applications.
Ramnivas Laddad said just one kind of AOP won't fit all applications and choosing the right combination will help developers be successful with AOP. He did a presentation at the recent SpringOne Americas conference on the various AOP design and implementation choices Spring AOP framework offers and the best practices in using it in the web applications.
Ramnivas discussed the advantages and limitations of AspectJ weaving and proxy-based Spring AOP approach. Choosing between Spring AOP and AspectJ depends on some design and environmental factors. Use Spring AOP in the following scenarios:
- Method-only interception is sufficient.
- Full power of AOP is overwhelming.
- Don't want to use a special compiler such as AspectJ compiler (ajc).
- Domain object cross-cutting is not needed.
- Pre-written aspects meet your needs.
Use AspectJ AOP in all other scenarios. He listed some of the example applications of AspectJ (fine grained tracing and monitoring, domain objects, fine-grained security) and proxy AOP (transaction management, JMX monitoring, remoting, and security). In the presentation, Ramnivas showed the differences between traditional AspectJ and @AspectJ syntax options with code examples.
Aspect weaving choices include compile-time or load-time weaving (LTW). When using LTW option, you can use the Spring-driven LTW which allows aspect weaving without any container launch script modifications (no -javaagent) or using Spring's JPA agent using
- Weaving cost at build time but full speed load-time.
- Build system modifications are needed.
- No deployment changes are required.
- Best IDE support with Eclipse AspectJ Development Tools (AJDT).
- Load-time speed, memory footprint affected.
- Build system unchanged but deployment changes are needed to weave aspects.
- No IDE tool support.
AOP design choices include the pointcut implementation utilizing the join point signatures and using wildcards to select a wide range of join points. Metadata (Annotations) can also be used to capture the join points, which offers the following advantages and disadvantages:
Annotations are an easy way to capture certain crosscutting concerns in the applications. They help limit the collaboration between aspect and classes to just annotations.
The collaboration from classes is needed. Also, the overuse of Annotations may obscure AOP's obliviousness property.
Some of the best practices in using metadata for AOP implementation are:
- Annotations are best for expressing the inherent characteristics of a program element.
- They should describe what is true at the join point - not what should happen at those points.
- Avoid implementation-specific annotations
- Annotations should describe what is true at the annotated element. For example, to capture a read only scenario, use @ReadOnly as the annotation name and not @TakeReadLock. And to mark a method that needs to be transactional, use @Transactional and not @JTATransactional.
- Don't use annotations to create macros.
- Use annotations that already exist like JPA (@Entity, @Table), JAX-WS (@WebService, @WebMethod), Spring (@Component, @Service, @Autowired, @ManagedResource).
AspectJ Hybrid Load-Time Weaving
AspectJ Hybrid Load-Time Weaving
JXInsight 5.6 extends it load-time weaving cache to now store the transformed bytecode image across application executions turning load-time weaving into binary weaving on consecutive executions. Our approach makes the switch between load-time weaving and binary weaving transparent - the first time an application is executed JXInsight will use load-time weaving the second time it uses binary weaving via the persisted transformed bytecode from the initial load-time weaving transformation. This reduces the (re)start-up time as well as the memory footprint - both which is extremely important in production environments.
This is a much better solution and one that still allows you to turn off the instrumentation of particular libraries without requiring a complete application rebuild. We have various filtering mechanisms in front of our load-time weaving agent.
In 5.7 we have additional load-time weaving optimizations including byte code compression.