Spring-boot: Better Caffeine Configuration

[mvpcortes]

Hi,

The configuration of Caffeine cache is limited because we should configure using spring.cache.caffeine.spec and spring.cache.cache-names.

I think caffeine cache can be configured using a better way:

spring.cache.caffeine.cache[0].name=a
spring.cache.caffeine.cache[0].spec=maximumSize=1000,expireAfterWrite=1000s
spring.cache.caffeine.cache[1].name=b
spring.cache.caffeine.cache[1].spec=maximumSize=1000,expireAfterWrite=1d

Or it could select a spec using regex over cache name. In this way we do not have to define all caches of applications. Only the builders for caches based on regex.

spring.cache.caffeine.builder[0].regex=.*1000_s.*
spring.cache.caffeine.builder[0].spec=maximumSize=1000,expireAfterWrite=1000s
spring.cache.caffeine.builder[1].regex=.*1_d.*
spring.cache.caffeine.builder[1].spec=maximumSize=1000,expireAfterWrite=1d

thanks!

[ben-manes]

You might try https://github.com/stepio/coffee-boots

Caffeine support is a direct port of the original Guava support. I don’t know why a single configuration was supported, but it seems intentional and workarounds like the above are suggested. Also note that Spring Cache is meant as a simple abstraction and its authors suggest using the implementation directly for advanced cases.

[snicoll]

@mvpcortes this was raised and declined already see, for instance, https://github.com/spring-projects/spring-framework/pull/1506.

In general, we don't want to expose a configuration infrastructure that lets you program by properties and exposing the builder that way feels very much like it to me. The project @ben-manes referenced goes in that direction so if that works for you, feel free to use it.

[mvpcortes]

Hi @snicoll, thanks your answer. I undestand the way that project deal with configuration ifnrastructure. And I agree to after I reading your answer and thinking about. @ben-manes Thanks by send project coffee-boots. I will see it .

[CH-EricLundberg]

I know this is closed, but my own take from a functional perspective is that this would be configuration by configuration, not programming by configuration. And would be handy to have since different envs can use different caching configurations for different needs. I can create beans for each cache that have @Value in them wired up to my own config values, but that seems like writing a bunch of boilerplate which the config files should hopefully let me avoid. Anyway just my two cents, I know everyone sees things differently.