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

[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on ISPN-4919 at 11/26/14 11:31 AM: ---------------------------------------------------------------------- Tristan, some comments and questions based on our discussion yesterday about representing templates and sets of instantiated caches. Templates: I assume you want to define templates within the scope of a cache container, maybe like this: {code:xml} <infinispan> <cache-container> <templates> <local-cache name="some-local-cache-template" extends="..." </templates> <local-cache/> <invalidation-cache/> </cache-container> </infinispan> {code} This means the same template can't be used across different cache containers. They could be defined external to cache containers: {code:xml} <infinispan> <templates> <local-cache name="some-local-cache-template" extends="..." </templates> <cache-container> <local-cache/> <invalidation-cache template="some-invalidation-cache-template"/> </cache-container> </infinispan> {code} You could even have cache-container templates thrown in as well, if there is a need for it. I think keeping them user a separate <templates/> element makes reading configurations a lot easier. And whether a cache is defined via a template or not, it's instance still appears as a resource named as {code} /subsystem=infinispan/cache-container=X/local-cache=Y {code} where the final cache configuration is the result of template processing. If once instantiated, you wanted to change the cache definition, then adding elements/attributes to the cache resource override elements/attributes defined in the template. In order to change the underlying template values, you would have to change the template resource itself. Sets of instantiated caches: For the <caches/> element, it represents a set of caches which have been instantiated from a common template. Because the caches in the set are of a common type, we could add nested element/attribute overrides to the <caches/> element which would apply to all caches and override the element/attribute values in the template. Also, the cache instances need to be placed somewhere in the model so that we can see the runtime attributes of the individual cache instances.. The only way I can think of handling this is to define a named cache-set: {code:xml} <infinispan> <cache-container> <templates> <local-cache name="some-local-cache-template" extends="..." </templates> <cache-sets> <cache-set name="some-cache-set" template="some-local-cache-template" names="some-name some-other-name"/> </cache-sets> <local-cache/> <invalidation-cache/> </cache-container> </infinispan> {code} and these would be represented in the model as {code} /subsystem=infinispan/cache-container=X/cache-set="some-cache-set"/local-cache="some-name" /subsystem=infinispan/cache-container=X/cache-set="some-cache-set"/local-cache="some-other-name" {code} You could have add/remove operations on the cache-set resource to change the set of caches. Because of the fact that the caches in the set are derived from a common template, you could arrange that changes to overridden values apply to the set as a whole. Changing the overriden value of one cache in the set would not be possible, as it would break the set semantics. was (Author: rachmato): Tristan, some comments and questions based on our discussion yesterday about representing templates and sets of instantiated caches. Templates: I assume you want to define templates within the scope of a cache container, maybe like this: {code:xml} <infinispan> <cache-container> <templates> <local-cache name="some-local-cache-template" extends="..." </templates> <local-cache/> <invalidation-cache/> </cache-container> </infinispan> {code} This means the same template can't be used across different cache containers. They could be defined external to cache containers: {code:xml} <infinispan> <templates> <local-cache name="some-local-cache-template" extends="..." </templates> <cache-container> <local-cache/> <invalidation-cache template="some-invalidation-cache-template"/> </cache-container> </infinispan> {code} You could even have cache-container templates thrown in as well, if there is a need for it. I think keeping them user a separate <templates/> element makes reading configurations a lot easier. And whether a cache is defined via a template or not, it's instance still appears as a resource named as {code} /subsystem=infinispan/cache-container=X/local-cache=Y {code} Adding elements/attributes to the cache resource override elements/attributes defined in the template. Sets of instantiated caches: For the <caches/> element, it represents a set of caches which have been instantiated from a common template. Because the caches in the set are of a common type, we could add nested element/attribute overrides to the <caches/> element which would apply to all caches and override the element/attribute values in the template. Also, the cache instances need to be placed somewhere in the model so that we can see the runtime attributes of the individual cache instances.. The only way I can think of handling this is to define a named cache-set: {code:xml} <infinispan> <cache-container> <templates> <local-cache name="some-local-cache-template" extends="..." </templates> <cache-sets> <cache-set name="some-cache-set" template="some-local-cache-template" names="some-name some-other-name"/> </cache-sets> <local-cache/> <invalidation-cache/> </cache-container> </infinispan> {code} and these would be represented in the model as {code} /subsystem=infinispan/cache-container=X/cache-set="some-cache-set"/local-cache="some-name" /subsystem=infinispan/cache-container=X/cache-set="some-cache-set"/local-cache="some-other-name" {code} You could have add/remove operations on the cache-set resource to change the set of caches. Because of the fact that the caches in the set are derived from a common template, you could arrange that changes to overridden values apply to the set as a whole. Changing the overriden value of one cache in the set would not be possible, as it would break the set semantics. -- This message was sent by Atlassian JIRA (v6.3.8#6338)