Summary

The doc can be interpreted such that spring.cache.type=none disables caching, when in fact it's not really what it does. The documentation or behavior of Spring Boot should be improved in this regard.

Details

If you want to disable caching, you'll quickly find this in the documentation:

When @EnableCaching is present in your configuration, a suitable cache configuration is expected as well. If you need to disable caching altogether in certain environments, force the cache type to none to use a no-op implementation, as shown in the following example: spring.cache.type=none

So you do that and think your caching is disabled but if you have an explicit CacheManager configured, it is not. This is because all cache configs are @Conditional({ CacheCondition.class }) and @ConditionalOnMissingBean(CacheManager.class).

Therefore, if you specify spring.cache.type=none, all that happens is that NoOpCacheConfiguration will be loaded if there is no CacheManager bean.

This is partially explained in the docs:

If you have not defined a bean of type CacheManager or a CacheResolver named cacheResolver (see CachingConfigurer), Spring Boot tries to detect the following providers (in the indicated order): 1. Generic 1. JCache (JSR-107) (EhCache 3, Hazelcast, Infinispan, and others) 1. Hazelcast 1. Infinispan 1. Couchbase 1. Redis 1. Caffeine 1. Cache2k 1. Simple

In this list, None is missing, even though NoOpCacheConfiguration is also considered, further contributing to the confusion.

I think that: 1. The doc should make very clear that none only applies when the CacheManager is auto-configured, not if it's explicitly specified. 2. Or, none should disable caching even if there is an explicit CacheManager 3. Or, Spring Boot should throw an error when an explicit CacheManager is specified and spring.cache.type is none 4. None should also be listed

Comment From: pernelkanic

Can I take up this issue?

Comment From: wilkinsona

Thanks for your interest in contributing but we generally find documentation updates are better handled by the core team.

I'm not sure if we have any at the moment, but please keep an eye out for unassigned issues labelled with ideal for contribution or, if you haven't contributed before, first-timers only.

Comment From: snicoll

The doc can be interpreted such that spring.cache.type=none disables caching, when in fact it's not really what it does. The documentation or behavior of Spring Boot should be improved in this regard

I am more than happy to improve the doc but I fail to see what the exact problem this causes. None configures a no-op cache manager that effectively has the same effect as if the cache was not used at all. The advantage is that it still triggers an error if you're trying to use a cache that doesn't exist (and should).

Therefore, if you specify spring.cache.type=none, all that happens is that NoOpCacheConfiguration will be loaded if there is no CacheManager bean.

This is the exact same behavior for anything auto-configuration related. If you're taking control over things, we don't override your decisions. I am not sure I am following the argument. If you set spring.cache.type=redis, it won't provide a redis-based cache manager either if your app defines a CacheManager already What is the difference?

You're also turning your setup into a general problem that it isn't. If you have @EnableCaching on your @SpringBootApplication, and your CacheManager configuration in a separate configuration class, as you should, then your configuration is not taken into account and this makes sure we don't attempt to auto-configurate another cache manager for your slice tests.

I disagree with 1, 2, and 3 for the reason above. 4 is indeed an oversight.

Thoughts?

@pernelkanic hopefully the above should explain further what Andy stated above.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: snicoll

In this list, None is missing, even though NoOpCacheConfiguration is also considered, further contributing to the confusion.

No it isn't. Technically it is part of the CacheType enum but only for the purpose of binding and auto-completion. SIMPLE that is before it will always match if we go up to that point as it doesn't have any condition. So 4 isn't an oversight, after all. That said, I've reviewed the sections based on your feedback and rephrased things to be more explicit.

Comment From: ssatguru

Wasted half a day trying to understand why "spring.cache.type=none" wasn't taking effect. Googling , led me to this issue/discussion which is when I realized it wasn't taking effect as our app had a cache manager explicitly configured. A simple line in doc stating that "none" only works when CacheManager is auto-configured and not explicitly configured would have saved us the frustration. The current documentation leads one to believe setting spring.cache.type is a quick and easy way to disable cache.

Comment From: snicoll

@ssatguru every single feature in Spring Boot that works by configuring things using configuration properties (like spring.cache.type) operates on the assumption that the component is auto-configured. If you did the opposite, you may very well be that other party moaning that you configured the CacheManager yourself and some property in the environment was changing your explicit configuration. The former is much more healthy than the latter and that's a general principle in Spring Boot.

Comment From: ssatguru

Frankly I don't follow you at all. Nobody is asking you to change the way caching works, all we are asking you guys is to add a simple sentence in the doc to clarify this part. Anyway some mechanism should be provided to quickly disable cache, no matter if it has been configured by user or auto configured by spring. As an aside, spring continues to become opaque and obtuse day by day.

Comment From: philwebb

@ssatguru The problem we have is that all auto-configuration works in the same way and the concepts are universal. If we add a note to the caching section, we potentially have to add a note to all sections. We'd rather keep the basic concepts centralized to keep the individual documentation sections manageable.

Anyway some mechanism should be provided to quickly disable cache, no matter if it has been configured by user or auto configured by spring.

That's pretty difficult since once you define a CacheManager bean, you are taking control. You could always use a @Profile to enable/disable the bean creation.

As an aside, spring continues to become opaque and obtuse day by day.

You are welcome to your opinion, but please remember we are a small team trying to provide software and support for free. We try our best to document the way that things work and we provide all the source code exactly so that folks can see exactly what's going on. If you don't like the auto-configuration aspects of Spring Boot, you can exclude that module and wire everything up yourself. That will add a fair amount of code to your application, but everything will be explicit.