March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-820) Resolve {@link} links in configuration reference

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-820?page=com.atlassian.jira.plugin.s... ] Dan Berindei reassigned ISPN-820: --------------------------------- Assignee: Dan Berindei (was: Pete Muir) > Resolve {@link} links in configuration reference > ------------------------------------------------- > > Key: ISPN-820 > URL: https://issues.jboss.org/browse/ISPN-820 > Project: Infinispan > Issue Type: Feature Request > Components: Documentation-Core > Reporter: Galder Zamarreño > Assignee: Dan Berindei > > Currently configuration reference documentation does not resolve {@link} links. > It'd be nice if it'd point to the javadoc of the corresponding class if available! > Examples: > - Fully qualified class name of a class that looks up a reference to a {@link javax.transaction.TransactionManager}. The default provided is capable of locating the default TransactionManager in most popular Java EE systems, using a JNDI lookup. (Javadoc) > - Fully qualified name of the class that the configured {@link org.infinispan.marshall.Externalizer} can marshall/unmarshall. Establishing the link between type marshalled and {@link org.infinispan.marshall.Externalizer} implementations enables users to provide their own marshalling mechanisms even for classes which they cannot modify or extend. (Javadoc) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1279) Update links in documentation to point to 5.0 version of API docs

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-1279?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-1279. -------------------------------- Resolution: Out of Date > Update links in documentation to point to 5.0 version of API docs > ----------------------------------------------------------------- > > Key: ISPN-1279 > URL: https://issues.jboss.org/browse/ISPN-1279 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Reporter: Martin Gencur > Assignee: Pete Muir > > Documents at https://docs.jboss.org/author/display/ISPN (user guide, tutorials, etc.) should point (via links) to newer API documentation (http://docs.jboss.org/infinispan/5.0/apidocs/). Now they point to 4.0 API docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1474) Refine fluent API for boolean configuration properties

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-1474?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-1474 at 3/11/14 8:59 AM: ------------------------------------------------------------- Fixed in the new configuration, introduced with ISPN-1538. was (Author: dan.berindei): Fixed in the new configuration, introduced with ISPN-1358. > Refine fluent API for boolean configuration properties > ------------------------------------------------------ > > Key: ISPN-1474 > URL: https://issues.jboss.org/browse/ISPN-1474 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 5.1.0.BETA2 > Reporter: Paul Ferraro > Assignee: Pete Muir > Fix For: 5.1.0.FINAL > > > The following configuration properties lack an API mechanism for disabling their functionality once enabled: > invocationBatching > jmxStatistics > Some configuration properties cannot be re-enabled once disabled. > e.g. for indexing, calling config.fluent().indexing().disable().indexing() will disable then re-enable indexing. However, this does not work for the following properties: > l1Caching > While I'm at it, there seem to be 2 mechanisms for dealing with boolean properties. > Either the property is auto-enabled with an option to disable: > e.g. > config.fluent().indexing().disable() > or, the property is enabled/disabled explicitly: > e.g. > config.fluent().hashing().groups().enabled(Boolean) > config.fluent().hashing().rehashEnabled(Boolean) > Is there any reason why one approach is preferred over the other? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1474) Refine fluent API for boolean configuration properties

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-1474?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-1474. -------------------------------- Fix Version/s: 5.1.0.FINAL Resolution: Out of Date Fixed in the new configuration, introduced with ISPN-1358. > Refine fluent API for boolean configuration properties > ------------------------------------------------------ > > Key: ISPN-1474 > URL: https://issues.jboss.org/browse/ISPN-1474 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 5.1.0.BETA2 > Reporter: Paul Ferraro > Assignee: Pete Muir > Fix For: 5.1.0.FINAL > > > The following configuration properties lack an API mechanism for disabling their functionality once enabled: > invocationBatching > jmxStatistics > Some configuration properties cannot be re-enabled once disabled. > e.g. for indexing, calling config.fluent().indexing().disable().indexing() will disable then re-enable indexing. However, this does not work for the following properties: > l1Caching > While I'm at it, there seem to be 2 mechanisms for dealing with boolean properties. > Either the property is auto-enabled with an option to disable: > e.g. > config.fluent().indexing().disable() > or, the property is enabled/disabled explicitly: > e.g. > config.fluent().hashing().groups().enabled(Boolean) > config.fluent().hashing().rehashEnabled(Boolean) > Is there any reason why one approach is preferred over the other? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1295) Deprecate transport properties and replace with configuration on transport itself

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-1295?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-1295: ------------------------------- Assignee: Galder Zamarreño (was: Pete Muir) > Deprecate transport properties and replace with configuration on transport itself > --------------------------------------------------------------------------------- > > Key: ISPN-1295 > URL: https://issues.jboss.org/browse/ISPN-1295 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 5.0.0.CR8 > Reporter: Pete Muir > Assignee: Galder Zamarreño > > Currently transport properties are detyped and confusing for users as it sounds like the should actually configure properties of the transport, not properties of the transport configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1757) Use a ConsistentHashFactory for consistent hash configuration

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-1757?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-1757. -------------------------------- Assignee: Dan Berindei (was: Pete Muir) Fix Version/s: 5.2.0.Final Resolution: Done Fixed with ISPN-1424. > Use a ConsistentHashFactory for consistent hash configuration > ------------------------------------------------------------- > > Key: ISPN-1757 > URL: https://issues.jboss.org/browse/ISPN-1757 > Project: Infinispan > Issue Type: Task > Components: Configuration > Affects Versions: 5.1.0.CR4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.2.0.Final > > > The new programmatic configuration allows the user to configure a consistent hash with `HashConfigurationBuilder.consistentHash(ConsistentHash)`. > Since we always create new instances of the consistent hash, I think it would be nicer if we had `HashConfigurationBuilder.consistentHashFactory(ConsistentHashFactory)` instead. > This would also allow us to have a single default factory that can choose between creating a `DefaultconsistentHash` or a `TopologyAwareConsistentHash` based on the transport configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3957) Preload with async cache store is not efficient

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3957?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3957: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059489, https://bugzilla.redhat.com/show_bug.cgi?id=1060199, https://bugzilla.redhat.com/show_bug.cgi?id=1075061 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1059489, https://bugzilla.redhat.com/show_bug.cgi?id=1060199) > Preload with async cache store is not efficient > ----------------------------------------------- > > Key: ISPN-3957 > URL: https://issues.jboss.org/browse/ISPN-3957 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.7.Final > Reporter: Mircea Markus > Assignee: Dan Berindei > Labels: 621 > Fix For: 5.2.8.Final, 7.0.0.Alpha1, 7.0.0.Final > > > Configuring on a AdvancedCacheLoader preload=true and asyn=true cause it to load each entry in the store in a loop, each entry being loaded through an store read. > This is caused by the way loadAll is implemented in the AsynLoader: in order to enforce consistency with whatever is in memory it does some special handling. The thing is, though, that we don't need this advanced async loader logic during the initial preload, as the async cache loader is empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4079) Enhance Cache addListener method to match types for filter and converter

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4079?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4079: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2423 > Enhance Cache addListener method to match types for filter and converter > ------------------------------------------------------------------------ > > Key: ISPN-4079 > URL: https://issues.jboss.org/browse/ISPN-4079 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > While having discussion about listeners types came up and made me realize we don't match types to the Cache for the filter and converter currently, which should be doable. > http://lists.jboss.org/pipermail/infinispan-dev/2014-March/014683.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1242) Add dynamic grouping capabilities for unmodifiable key classes.

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-1242?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-1242: ---------------------------------- Assignee: Dan Berindei (was: Pete Muir) > Add dynamic grouping capabilities for unmodifiable key classes. > --------------------------------------------------------------- > > Key: ISPN-1242 > URL: https://issues.jboss.org/browse/ISPN-1242 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.0.0.CR7 > Reporter: Erik Salter > Assignee: Dan Berindei > > The grouping API should be enhanced to add grouping capabilities to a a cache's put() or replace() methods. > This encompasses the following scenario: > Cache A uses a custom key class where the group is dynamically generated. Cache B's key is an unmodifiable String that needs to be grouped with the dynamic value of a key from Cache A. (Cache B's key can't be encapsulated in a custom key class since it needs to be queried from external entities that will not know the group context). > And in pseudo-code: > {code} > Group class InternalResourceKey { > String group; > ... > @Group > String getGroup() { > return group; > } > } > InternalResourceKey key = new InternalResourceKey(); > {code} > ... > {code} > resourceCache.lock( key ); > // Get the previous result. > ResourceResult result = resourceCache.get( key ); > ResourceResult newResult = doWork( key, result ); > resourceCache.put( key, newResult ); > // I also want to group an external identifier that an external client knows about with the result so they will be on the same node > employeeCache.put( "111-111-1111", newResult, key.getGroup() ); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4092) ViewChangedEvent.getOldMembers() and getNewMembers() should never be null

by Thomas Fromm (JIRA)

[ https://issues.jboss.org/browse/ISPN-4092?page=com.atlassian.jira.plugin.... ] Thomas Fromm commented on ISPN-4092: ------------------------------------ Assign stuff to me on what I worked on 2y ago is pretty optimistic ;-) However, you're right. I'm not sure if the same event object is used at all listeners, so maybe this must be implemented thread safe. > ViewChangedEvent.getOldMembers() and getNewMembers() should never be null > ------------------------------------------------------------------------- > > Key: ISPN-4092 > URL: https://issues.jboss.org/browse/ISPN-4092 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Eric Bonnot > Assignee: Thomas Fromm > Priority: Minor > > Simply for more comfort at usage I'd like to have ViewChangedEvent changed, that the list-getter never return null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014