Sample app showing how to use AspectJ natively with @Aspect and Spring Boot.
AspectJ lets you write aspects using Java annotations @Aspect and friends. Conveniently, but sometimes confusingly, Spring lets you use the same programming model, and then uses the AspectJ tooling APIs at runtime, so some people can’t tell the difference between Spring AOP and AspectJ. You don’t need any special tools to use Spring AOP, but it has it’s limitations, one of which is performance (you take a hit on startup while all the beans are analysed, and you take another smaller hit when the app is running and one of your aspects is executed through a proxy).
Luckily, it is quite easy to set up AspectJ to weave your code natively (not with Spring), and it is sometimes faster - just more steps to set up. In fact, there are multiple ways of using AspectJ to weave your code, some of which happen at runtime, and one (broadly speaking) that happens at compile time. Comile time is faster (unsurprisingly), but not massively (heuristically, maybe a 20% effect).
|
Note
|
AspectJ 1.8.13 (included with Spring Boot 1.5.9) has some major performance improvements affecting Spring AOP - the optimizations were suggested by running the benchmarks in this project. If you think Spring AOP might be slowing your app down on startup, upgrade now. |
-
spring = Spring AOP standalone sample. Aspects and application code in the same module.
-
ltw = Load Time Weaving standalone sample. Aspects and application code in the same module.
-
ctw = Compile Time Weaving standalone sample. Aspects and application code in the same module.
-
multi-ltw = Load Time Weaving multi-module sample. Aspects and application code in separate modules.
-
multi-ctw = Compile Time Weaving multi-module sample. Aspects and application code in separate modules. The aspect library (as well as the application) has to be processed by AspectJ at build time.
-
timing = A utility library for logging timing data on startup for some internal features of Spring and Spring Boot
You need to tell AspectJ where to find your aspects, and which classes you want it to weave. You also need to tell Spring not to try and weave the same aspects again (in Spring Boot you can do that with spring.aop.auto=false). The configuration for AspectJ lives in an XML file aop.xml, which can be in META-INF or in a package called org.aspectj. Here’s a simple example:
<!DOCTYPE aspectj PUBLIC "-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd">
<aspectj>
<weaver>
<include within="com.example.*" />
<include within="org.springframework.boot..*" />
</weaver>
<aspects>
<aspect name="com.example.Interceptor" />
</aspects>
</aspectj>|
Warning
|
If the AspectJ config file is in META-INF/aop.xml then the fat jar built by Spring Boot has it is in the wrong place, and there are nasty looking errors on startup. The app still works and the aspects are woven, but you can work around it by putting aop.xml in the org.aspectj package instead of in META-INF.
|
One of the runtime options is called "load time weaving", and Spring even has an annotation @EnableLoadTimeWeaving to help get it off the ground. The Spring annotation is rooted in the culture and mechanics of application servers - it only makes sense if you have multiple apps running in the same JVM with class loader isolation. What happens is that it uses a special ClassLoader that manipulates the classes as they are loaded.
The other option for load time weaving is the AspectJ agent, which you add to the JVM on the command line, and it can look at all the classes and potentially weave them with aspects.
E.g. :
$ cd ltw
$ mvn clean install
$ java -javaagent:$HOME/.m2/repository/org/aspectj/aspectjweaver/1.8.13/aspectjweaver-1.8.13.jar -jar target/*.jarIf you don’t add the agent (and don’t provide an implementation of Interceptor.aspectOf()) you might get a confusing "cyclic dependency" error from Spring on startup. It’s not really cyclic, but because the Interceptor in this sample is an @EventListener Spring is trying to create it very early and gets confused. The real problem is just that Aspects.aspectOf() doesn’t work unless the agent is attached.
|
Note
|
@EnableLoadTimeWeaving doesn’t actually make much sense in a Spring Boot app that is going to run in its own process - you can just add the AspectJ agent. Many people confuse "load time weaving" with "runtime weaving" generally (because for a long time it was the only option for many Spring apps). So if someone asks you to implement "load time weaving" in a Spring Boot app, just add the agent.
|
|
Note
|
The "timing" library is a dependency of this project so it gets woven at runtime and prints out interesting (but verbose) information about timings for bean initialization. This is in addition to the aspects library. |
To weave the aspects at compile time (and also optionally use the AspectJ language, as opposed to Java with annotations), you need an additional plugin in your build. If all you need is to weave existing byte code, the plugin configuration is very simple:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.10</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<proc>none</proc> (1)
<complianceLevel>${java.version}</complianceLevel>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjtools</artifactId>
<version>${aspectj.version}</version> (2)
</dependency>
</dependencies>
</plugin>-
Useful if you have annotation processors (like Spring Boot configuration processor), to avoid them being processed again by the AspectJ compiler.
-
Optionally update the AspectJ tooling to the latest version. The
aspectrtjar has to be included separately.
In this sample build the app with the weave profile to run this plugin. E.g.
$ cd ctw
$ mvn clean install
$ java -jar target/*.jar|
Note
|
in the plugin configuration above, we haven’t asked AspectJ to weave the dependencies, and it won’t do that by default. Consequently we won’t see as much output from the app when it runs as we did with the runtime weaving (where all the classes were available for weaving as soon as they were loaded). |
|
Note
|
AspectJ is smart enough not to try and weave the same class twice, so you can always add the agent at runtime even when the application classes are already woven. That would be one way to pick up additional join points that you hadn’t woven at compile time. |
|
Note
|
The "timing" library is not a dependency of this project, and there wouldn’t be much point doing that because the pointcuts it defines would not match anything that was being compiled here. |
You can run the samples from the command line and see the aspect logging to stderr:
$ cd ltw
$ mvn spring-boot:run
...
execution(InterceptorApplication..EnhancerBySpringCGLIB..8ce66f62.setBeanFactory(..))
execution(InterceptorApplication..EnhancerBySpringCGLIB..8ce66f62.setBeanFactory(..))
...To run in the IDE you need to add the agent to your launch configuration.
-javaagent:${system_property:user.home}/.m2/repository/org/aspectj/aspectjweaver/1.8.13/aspectjweaver-1.8.13.jarNote that you could add @EnableLoadTimeWeaving to the main application class, but it should probably be removed, as it’s misleading.
There’s an open issue asking for @EnableLoadTimeWeaving support in Spring Boot, and a user who says he made it work with a PropertiesLauncher (because it can set the class loader really early): spring-projects/spring-boot#739. It doesn’t work to set the classloader in the main method because too many Spring Boot classes have already been loaded by then, but there is a trick you can play with [attaching the agent at runtime]http://www.eclipse.org/aspectj/doc/released/README-187.html (in which case all classes loaded up to that point can not be woven).
|
Note
|
You can enable logging of the weaving using -Daj.weaving.verbose=true.
|
Useful links: