[
https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-4919:
------------------------------------
[~pferraro] the way I see it, this issue is about allowing multiple inheritance
"roots" instead of forcing all the caches to inherit from the default cache. But
I'm only thinking about the embedded configuration, for the server configuration
it's probably different.
I imagine {{EmbeddedCacheManager.defineConfiguration(String cacheName, Configuration
configuration)}} still won't work once this issue is fixed. You'll still have to
{{read()}} the template configuration and apply your changes on the clone, just like the
XML parser does now with the default cache configuration.
Configuration templates
-----------------------
Key: ISPN-4919
URL:
https://issues.jboss.org/browse/ISPN-4919
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 7.1.0.Beta1
Currently there is a 1:1 relationship between configuration and named caches. While the
programmatic API does have the ability to .read() an existing configuration to create a
new one, the declarative config does not.
We should introduce the concept of configuration inheritance, e.g.:
{code}
<local-cache name="eviction-cache">
<eviction strategy="LIRS" maxEntries="10000"/>
</local-cache>
<local-cache name="mycache" template="eviction-cache" />
{code}
Possibly, cache templates should be made "abstract" so that they cannot be
instantiated as named caches directly, e.g.:
{code}
<local-cache name="eviction-cache" abstract="true">
...
</local-cache>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)