I'm trying to understand the functionality of cache abstraction when it is invoked via a @RequestMapping registered in a (MVC) @Controller class.
I setup a simple proof of concept where I had STS generate an MVC project. I configured the cache abstraction in the root context and tied it to Redis as the cache manager. I then created an arbitrary method on a class annotated as a @Service and declared that method to be @Cacheable. I wrote a simple junit test that would load the root context and trigger the method several times. Based on a print statement I could tell that the first time in, it would run the method, after that it would hit the cache. As expected.
I then had my @Controller call to the same method that was autowired in the controller, but no matter what it would never cache or read from cache, it would always enter the method. Not expected. In order to make it work I had to add the following statement to my servlet context:
With that in the servlet context (as well as the root context) the interactions started by the controller would then allow the caching in the service to function properly, as well as those triggered by the junit tests.
My question is why would I have to do this? I thought that the web context inherited everything from the root context with the ability to override. I'm assuming it has something to do with spring created proxies, but not really sure.
Also, is this the recommended way of doing this? I want caching to be functional on the mid-tier of my applications, and usable by both a testing framework as well as my MVC layer without having to declare annotation-driven multiple times all over the code. I suppose I could always create a test context that imports the root context for testing, but I wanted to get some insight from the community.