[infinispan-issues] [JBoss JIRA] (ISPN-4919) Configuration templates

Richard Achmatowicz (JIRA) issues at jboss.org
Wed Nov 26 12:03:39 EST 2014


    [ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023359#comment-13023359 ] 

Richard Achmatowicz edited comment on ISPN-4919 at 11/26/14 12:03 PM:
----------------------------------------------------------------------

You could do that if you had an cache attribute like cache-set="some-cache-set". - in that way, the caches belonging to the set could be identified and reconstituted into your <caches/> element when the model was persisted.. It would be read-only.


was (Author: rachmato):
You could do that if you had an cache attribute like cache-set="some-cache-set". - in that way, the caches belonging to the set could be identified and reconstituted into your <caches/> element..  

> 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.Alpha1
>
>
> 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)


More information about the infinispan-issues mailing list