Spring

In a Spring Boot Java Web App we had caching set up for several computationally expensive methods. After some time I discovered that the mechanism was apparently broken for those methods, but implementing a new cached method in a completely new service class worked. At first I tried to exclude simple errors as culprits. Method signatures of the cacheable methods were simplified, the @Cacheable method annotation was moved between interface and implementation methods as well as between data repositories and service classes. Another potential error may have come from Springs proxy functionality, which should create a proxy doing the caching for our service. This proved to be the problem - the needed proxy wasn’t generated and I had no clue why. I discovered some warning messages in the application startup logs like 'Bean XYZ is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)'. The proxy stuff for @Cacheable methods is also done via a BeanPostProcessors. It seemed that Spring initialized our service beans long before it manages to initialize the caching mechanism, which deprived them of the caching functionality. By setting a watcher in debug mode in the according class on this log message and tracing back the call stack of our service bean I was able to find out where and understand why our beans were prematurely initialized. In those two resulting classes I implemented a LazyInit feature that initialized our beans after the caching functionality has been initialized and caching started to work again.