[
https://issues.apache.org/jira/browse/JCS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ricard Nàcher Roig updated JCS-193:
-----------------------------------
Description:
I started using JCS cache as a JCache implementation provider a few days ago
and everything was fine until I needed to set up expiration for cached data or
even the number of elements stored in the cache. I realized that caches were
created with EternalPolicy so I started to figure out how to set up both
implementation specific properties and Standard JCache ones. After a couple of
days, I don't have a pretty idea about how to configure the caches related to
methods annotated with JCache annotations like CacheResult, CacheRemove and so
on.
I mean that I already know that I can use the CacheDefaults annotation, both at
class and method level, in order to set the name of the cache to be used. but
another thing is to also set the CacheResolverFactory. Should I always set the
CacheResolverFactory in the annotation in order to be able to create the cache
using a specific set of properties? Or maybe the idea is to create the cache
programmatically before is is needed? Anyway, It seems too much boilerplate to
me. Maybe I am wrong but I think that we are not using the CDI power at all.
and please, let me know if there is better/simpler approach.
Another thing that I cannot understand is the readConfig method of the
JCSCachingManager class. It is loading the folder structure because it is
loading the resources from the default uri of the provider!
where uri is "jcs://jcache.ccf", so the path is "/". I think that this URI
should not be used for this, maybe the uri should be something different (URI
of the default configuration?) or just use another implementation specific
property.
{code:java}
final Enumeration<URL> resources = loader.getResources(uri.getPath());
{code}
What about this?
Add CachingProvider and CacheManager as beans if they are not already beans.
Notice that this is what jcs-jcache-extras module already does!
So as a developer I can configure my CachingProvider and even the cache manager
already configured as beans. They will be injected where needed instead of
being created without configuration.
no configuration in CacheResolverFactory
{code:java}
public CacheResolverFactoryImpl()
{
provider = Caching.getCachingProvider();
cacheManager = provider.getCacheManager(provider.getDefaultURI(),
provider.getDefaultClassLoader());
}
{code}
but in JCacheFilter class some properties are set
{code:java}
manager = provider.getCacheManager(URI.create(uri), classLoader, properties);
{code}
One step further into CDI should be to also provide the CacheResolverFactory as
a bean and also the
CacheResolverFactoryImpl could be also injected with the cacheProvider and
CacheManager and some CompleteConfigurationResolver of something like that in
order to avoid creating caches with a hard-coded MutableConfiguration.
{code:java}
public class CacheResolverFactoryImpl implements CacheResolverFactory
{
...
private Cache<?, ?> createCache(final String exceptionCacheName)
{
cacheManager.createCache(exceptionCacheName, new
MutableConfiguration<Object, Object>().setStoreByValue(false));
return cacheManager.getCache(exceptionCacheName);
}
{code}
with these changes, we reduce boilerplate and give more control to jcs-jcache
library clients.
Can we move ExtraJCacheExtension to jcs-jcache in order to be able to handle
CachingProvider and CacheManager as beans?
best regards,
Ricard
was:
I started using JCS cache as a JCache implementation provider a few days ago
and everything was fine until I needed to set up expiration for cached data or
even the number of elements stored in the cache. I realized that caches were
created with EternalPolicy so I started to figure out how to set up both
implementation specific properties and Standard JCache ones. After a couple of
days, I don't have a pretty idea about how to configure the caches related to
methods annotated with JCache annotations like CacheResult, CacheRemove and so
on.
I mean that I already know that I can use the CacheDefaults annotation, both at
class and method level, in order to set the name of the cache to be used. but
another thing is to also set the CacheResolverFactory. Should I always set the
CacheResolverFactory in the annotation in order to be able to create the cache
using a specific set of properties? It seems too much boilerplate to me. Maybe
I am wrong but I think that we are not using the CDI power at all.
and please, let me know if there is better/simplier aproach.
Another thing that I cannot understand is the readConfig method of the
JCSCachingManager class. It is loading the folder structure because it is
loading the resources from the default uri of the provider!
where uri is "jcs://jcache.ccf", so the path is "/". I think that this URI
should not be used for this, maybe the uri should be something different (URI
of the default configuration?) or just use another implementation specific
property.
{code:java}
final Enumeration<URL> resources = loader.getResources(uri.getPath());
{code}
What about this?
Add CachingProvider and CacheManager as beans if they are not already beans.
Notice that this is what jcs-jcache-extras module already does!
So as a developer I can configure my CachingProvider and even the cache manager
already configured as beans. They will be injected where needed instead of
being created without configuration.
no configuration in CacheResolverFactory
{code:java}
public CacheResolverFactoryImpl()
{
provider = Caching.getCachingProvider();
cacheManager = provider.getCacheManager(provider.getDefaultURI(),
provider.getDefaultClassLoader());
}
{code}
but in JCacheFilter class some properties are set
{code:java}
manager = provider.getCacheManager(URI.create(uri), classLoader, properties);
{code}
One step further into CDI should be to also provide the CacheResolverFactory as
a bean and also the
CacheResolverFactoryImpl could be also injected with the cacheProvider and
CacheManager and some CompleteConfigurationResolver of something like that in
order to avoid creating caches with a hard-coded MutableConfiguration.
{code:java}
public class CacheResolverFactoryImpl implements CacheResolverFactory
{
...
private Cache<?, ?> createCache(final String exceptionCacheName)
{
cacheManager.createCache(exceptionCacheName, new
MutableConfiguration<Object, Object>().setStoreByValue(false));
return cacheManager.getCache(exceptionCacheName);
}
{code}
with these changes, we reduce boilerplate and give more control to jcs-jcache
library clients.
Can we move ExtraJCacheExtension to jcs-jcache in order to be able to handle
CachingProvider and CacheManager as beans?
best regards,
Ricard
> How to configure caches used by interceptors (i.e. CacheResultInterceptor)
> related to JCache annotations
> --------------------------------------------------------------------------------------------------------
>
> Key: JCS-193
> URL: https://issues.apache.org/jira/browse/JCS-193
> Project: Commons JCS
> Issue Type: Question
> Affects Versions: jcs-2.2
> Reporter: Ricard Nàcher Roig
> Priority: Major
>
> I started using JCS cache as a JCache implementation provider a few days ago
> and everything was fine until I needed to set up expiration for cached data
> or even the number of elements stored in the cache. I realized that caches
> were created with EternalPolicy so I started to figure out how to set up both
> implementation specific properties and Standard JCache ones. After a couple
> of days, I don't have a pretty idea about how to configure the caches related
> to methods annotated with JCache annotations like CacheResult, CacheRemove
> and so on.
> I mean that I already know that I can use the CacheDefaults annotation, both
> at class and method level, in order to set the name of the cache to be used.
> but another thing is to also set the CacheResolverFactory. Should I always
> set the CacheResolverFactory in the annotation in order to be able to create
> the cache using a specific set of properties? Or maybe the idea is to create
> the cache programmatically before is is needed? Anyway, It seems too much
> boilerplate to me. Maybe I am wrong but I think that we are not using the CDI
> power at all.
> and please, let me know if there is better/simpler approach.
> Another thing that I cannot understand is the readConfig method of the
> JCSCachingManager class. It is loading the folder structure because it is
> loading the resources from the default uri of the provider!
> where uri is "jcs://jcache.ccf", so the path is "/". I think that this URI
> should not be used for this, maybe the uri should be something different (URI
> of the default configuration?) or just use another implementation specific
> property.
> {code:java}
> final Enumeration<URL> resources = loader.getResources(uri.getPath());
> {code}
>
> What about this?
> Add CachingProvider and CacheManager as beans if they are not already beans.
> Notice that this is what jcs-jcache-extras module already does!
> So as a developer I can configure my CachingProvider and even the cache
> manager already configured as beans. They will be injected where needed
> instead of being created without configuration.
> no configuration in CacheResolverFactory
> {code:java}
> public CacheResolverFactoryImpl()
> {
> provider = Caching.getCachingProvider();
> cacheManager = provider.getCacheManager(provider.getDefaultURI(),
> provider.getDefaultClassLoader());
> }
> {code}
> but in JCacheFilter class some properties are set
>
> {code:java}
> manager = provider.getCacheManager(URI.create(uri), classLoader, properties);
> {code}
> One step further into CDI should be to also provide the CacheResolverFactory
> as a bean and also the
> CacheResolverFactoryImpl could be also injected with the cacheProvider and
> CacheManager and some CompleteConfigurationResolver of something like that in
> order to avoid creating caches with a hard-coded MutableConfiguration.
> {code:java}
> public class CacheResolverFactoryImpl implements CacheResolverFactory
> {
> ...
> private Cache<?, ?> createCache(final String exceptionCacheName)
> {
> cacheManager.createCache(exceptionCacheName, new
> MutableConfiguration<Object, Object>().setStoreByValue(false));
> return cacheManager.getCache(exceptionCacheName);
> }
> {code}
>
> with these changes, we reduce boilerplate and give more control to
> jcs-jcache library clients.
> Can we move ExtraJCacheExtension to jcs-jcache in order to be able to handle
> CachingProvider and CacheManager as beans?
> best regards,
> Ricard
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
