Spring's AspectJ-mode caching versus AspectJ-mode transactions

Question

My question relates to Spring's AspectJ mode and especially how to enable it for:

1. Transaction management
2. Caching

1) I noticed that in order to enable the AspectJ mode for transaction management, I only had to do the following:

@Configuration
@EnableTransactionManagement(mode = AdviceMode.ASPECTJ)

2) Whereas in order to use AspectJ mode for caching it seems one has to:

-Put the following jar into Tomcat's lib directory: org.springframework:spring-instrument-tomcat -Add the following line in Tomcat's server.xml:

<Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/>

-Add the following configuration:

@Configuration
@EnableLoadTimeWeaving(aspectjWeaving = AspectJWeaving.ENABLED)
public class LoadTimeWeavingConfiguration implements LoadTimeWeavingConfigurer {
    @Override
    public LoadTimeWeaver getLoadTimeWeaver() {
        return new ReflectiveLoadTimeWeaver();
    }
}

-to finally be able to use the AspectJ mode as follows:

@Configuration
@EnableCaching(mode = AdviceMode.ASPECTJ)

Is the above right? If so why is AspectJ-mode caching different from AspectJ-mode transaction support?

Answer 1

The extra configuration you listed for the @EnableCaching case is not any more needed than in the case of @EnableTransactionManagement. If you choose mode = AdviceMode.ASPECTJ it just means that it will use AspectJ instead of CGLIB proxies for the transaction management / cache functionality. If you have compile-time weaving enabled with spring-aspects-<version>.jar listed as an aspect library, it should work out of the box (given all other required transaction management / cache configuration related beans are available in the application context). If you're not using compile-time weaving but choose instead to go with load-time weaving, having -javaagent:/path/to/aspectjweaver-<version>.jar on the command line as a JVM argument is enough. The ReflectiveLoadTimeWeaver and TomcatInstrumentableClassLoader are only required in case no compile-time weaving is used in your build and a load-time weaving agent is not present in the VM, and you still want to have load-time weaving via classloading.