[JBoss JIRA] (ISPN-4919) Configuration templates
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on ISPN-4919:
-------------------------------------------
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)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-4919:
---------------------------------------
I would prefer if the actual caches themselves still "lived" directly under /subsystem=infinispan/cache-container=X/ even though they are instantiations of a common template, unless I could have them in both places as symlinks (as we discussed).
> 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)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on ISPN-4919 at 11/26/14 11:38 AM:
----------------------------------------------------------------------
Alternatively, the <caches/> element could be used as a one-off syntactic sugar for creating multiple cache definitions, which would then be written back to the schema as individual cache definitions. But that doesn't seem too useful.
was (Author: rachmato):
Alternatively, the <caches/> element could be used as a one-off syntactic sugar for creating multiple cache definitions, which would then me written back to the schema as individual cache definitions. But that doesn't seem too useful.
> 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)
11 years, 4 months
[JBoss JIRA] (ISPN-5025) Infinispan ArrayIndexOutOfBoundsException in ComponentMetadataPersister
by Uday Mareedu (JIRA)
Uday Mareedu created ISPN-5025:
----------------------------------
Summary: Infinispan ArrayIndexOutOfBoundsException in ComponentMetadataPersister
Key: ISPN-5025
URL: https://issues.jboss.org/browse/ISPN-5025
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Reporter: Uday Mareedu
Hi Team,
In my project we need to implement the caching for the application which is running in JBOSS. Basically I need to cache the objects from the servlet. I have downloaded the infinispan-7.0.2.Final-minimal to try it in eclipse.
Below is the very sample code to try.
import org.infinispan.Cache;
import org.infinispan.manager.DefaultCacheManager;
public class SimpleCaching {
static void main(String args[]) {
try {
System.out.print("Start");
Cache<Object, Object> c = new DefaultCacheManager().getCache();
c.put("key", "value");
c.putIfAbsent("key", "newValue");
System.out.print(c.get("key"));
} catch (Exception ex1) {
System.out.println(ex1.getMessage());
}
}
}
I have added all the dependencies, but I am getting "Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
at org.infinispan.factories.components.ComponentMetadataPersister.main(ComponentMetadataPersister.java:50)" exception.
I am very new to this, can anyone explain where I am missing.
Thanks in advance for your help!
Regards,
Uday Shankar.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on ISPN-4919:
-------------------------------------------
Alternatively, the <caches/> element could be used as a one-off syntactic sugar for creating multiple cache definitions, which would then me written back to the schema as individual cache definitions. But that doesn't seem too useful.
> 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)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Richard Achmatowicz (JIRA)
[ 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.
> 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)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on ISPN-4919:
-------------------------------------------
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.
> 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)
11 years, 4 months
[JBoss JIRA] (ISPN-5008) 7.0.x missing cachestore-remote and extended-statistics modules
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5008?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5008:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.1.0.Alpha1
Resolution: Done
> 7.0.x missing cachestore-remote and extended-statistics modules
> ---------------------------------------------------------------
>
> Key: ISPN-5008
> URL: https://issues.jboss.org/browse/ISPN-5008
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.2.Final
> Reporter: Ion Savin
> Assignee: Ion Savin
> Fix For: 7.1.0.Alpha1
>
>
> The distribution/package.xml script contains declaration for adding the two modules but they are not present in the package (7.0.0->7.0.2).
> {noformat}
> <module dir="${output.dir}" target="modules/infinispan-extended-statistics" module="extended-statistics" artifact="infinispan-extended-statistics" />
> <module dir="${output.dir}" target="modules/persistence/remote" module="persistence/remote" artifact="infinispan-cachestore-remote" />
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5007) Enhance the distribution script to detect missing artifacts
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5007?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5007:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.1.0.Alpha1
Resolution: Done
> Enhance the distribution script to detect missing artifacts
> -----------------------------------------------------------
>
> Key: ISPN-5007
> URL: https://issues.jboss.org/browse/ISPN-5007
> Project: Infinispan
> Issue Type: Feature Request
> Components: Build process
> Affects Versions: 7.0.2.Final
> Reporter: Ion Savin
> Assignee: Ion Savin
> Fix For: 7.1.0.Alpha1
>
>
> The build should fail if the maven artifacts to be copied into the distribution jar are not found.
> To reproduce the issue apply this patch (the build will succeed but the distribution .zip will not contain the uberjars):
> {noformat}
> diff --git a/all/pom.xml b/all/pom.xml
> index cecd6c6..779ed97 100644
> --- a/all/pom.xml
> +++ b/all/pom.xml
> @@ -25,7 +25,7 @@
> <executions>
> <execution>
> <id>mrproper</id>
> - <phase>prepare-package</phase>
> + <phase>initialize</phase>
> <goals>
> <goal>clean</goal>
> </goals>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months