CXF-9237 - Add possibility to configure JCache expiry time - #3370
CXF-9237 - Add possibility to configure JCache expiry time#3370coheigea wants to merge 1 commit into
Conversation
| // cacheTTLs lets the access/refresh token caches be evicted by the JCache infrastructure | ||
| // itself once entries age out, independently of any application-level expiry check; | ||
| // a TTL <= 0 (CacheTTLs.ETERNAL by default) leaves the corresponding cache eternal | ||
| public JCacheOAuthDataProvider(String configFileURL, |
There was a problem hiding this comment.
@coheigea thanks for the change, what concerns me is that cacheTTLs gives a wrong impression that TTL will be configured for each cache, but that is not the case: if the configuration has dedicated cache preset (like below)
<cache alias="cxf.oauth2.accesstoken.cache">
<key-type>java.lang.String</key-type>
<value-type>org.apache.cxf.rs.security.oauth2.common.ServerAccessToken</value-type>
<heap unit="entries">100</heap>
<jsr107:mbeans enable-management="false" enable-statistics="false"/>
</cache>the cacheTTL will be effectively ignored. I don't want to complicate it but also looking for intuitive API usage, may be instead of CacheTTLs cacheTTLs we introduce something like JCacheCreator (or alike) that will be used to create a cache when the is no one in configuration? Wdyt?
There was a problem hiding this comment.
Something along these lines:
interface JCacheCreator {
<K, V> Cache<K, V> createCache(CacheManager cacheManager, String cacheKey, MutableConfiguration<K, V> config);
}There was a problem hiding this comment.
Thanks @reta , maybe in that case we don't need this improvement at all if the user can configure the TTL in the config?
There was a problem hiding this comment.
Thanks @coheigea , that is also a valid point, we may not even need it
2 participants
By default there is no eviction for backwards compatibility