Open
Description
cache2k has no standard way of a central programmatic configuration at the moment.
The Spring support of cache2k allows that, e.g.:
@Bean
public CacheManager cacheManager() {
return new SpringCache2kCacheManager()
.defaultSetup(b->b.entryCapacity(2000))
.addCaches(
b->b.name("countries"),
b->b.name("test1").expireAfterWrite(30, TimeUnit.SECONDS).entryCapacity(10000),
b->b.name("anotherCache").entryCapacity(1000)).permitNullValues(true);
}
A similar scheme would be great for the org.cache2k.CacheManager
. Requirements:
- A
org.cache2k.CacheManager
can live within a DI container and is accepting programmatic configuration per cache, addressed by cache name - This is an alternative for a central cache configuration via XML
- In contrast to the Spring approach, where cache instances are created with the
SpringCache2kCacheManager
creation, the mechanism should only contain the configuration, which is before or after (?) the cache is build when the code uses it - In the long run this replaces the separate
SpringCache2kCacheManager
configuration approach - This plays well with the customizer interfaces used by Spring, so a
Cache2kCacheManagerCustomizer
becomes useful with this ability - If no DI container is used, it needs to be ensured that the central programmatic configuration is run first and populates the cache manager. This could be done via the serviceloader by declaring it as a
Cache2kExtensionProvider