[JBoss JIRA] (ISPN-9587) Key Transformer registration via config
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9587?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9587:
----------------------------------
Fix Version/s: 9.4.1.Final
(was: 9.4.0.Final)
> Key Transformer registration via config
> ---------------------------------------
>
> Key: ISPN-9587
> URL: https://issues.jboss.org/browse/ISPN-9587
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying, Remote Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Priority: Major
> Fix For: 9.4.1.Final
>
>
> Under indexing config element:
> {code}
> <key-transformers>
> <key-transformer key="org.infinispan.query.test.CustomKey" transformer="org.infinispan.query.test.CustomTransformer"/>
> </key-transformers>
> {code}
> and also via the config builder API.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-9443) Fail when single region is accessed with multiple strategies
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9443?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9443:
----------------------------------
Fix Version/s: 9.4.1.Final
(was: 9.4.0.Final)
> Fail when single region is accessed with multiple strategies
> ------------------------------------------------------------
>
> Key: ISPN-9443
> URL: https://issues.jboss.org/browse/ISPN-9443
> Project: Infinispan
> Issue Type: Enhancement
> Components: Hibernate Cache
> Affects Versions: 9.3.1.Final
> Reporter: Radim Vansa
> Priority: Major
> Fix For: 9.4.1.Final
>
>
> When we have two entities that share the same region but use different access strategies the Hibernate boot should fail. Right now there's an assertion in {{DomainDataRegionImpl.prepareFor*}} but this does not give much explanation and does not fail when assertions are disabled which leads to cryptic errors later on.
> Example:
> {code}
> @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE, region = "item")
> public static class NonStrictReadWriteVersionedCacheableItem { ... }
> @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "item")
> public static class ReadWriteVersionedCacheableItem { ... }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-9541) Module initialization is not thread-safe
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9541?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9541:
----------------------------------
Fix Version/s: 9.4.1.Final
(was: 9.4.0.Final)
> Module initialization is not thread-safe
> ----------------------------------------
>
> Key: ISPN-9541
> URL: https://issues.jboss.org/browse/ISPN-9541
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Server
> Affects Versions: 9.4.0.CR3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.1.Final
>
>
> In my ISPN-9127 fix I created a {{BasicComponentRegistry}} interface that represents a mostly-read-only collection of components. It has {{replaceComponent()}} method and a {{rewire()}} method for testing purposes, but it turns out modules were also relying on the ability to replace existing components in order to work.
> Replacing global components is normally safe during the {{ModuleLifecycle.cacheManagerStarting()}}, because none of the components are started yet, so when a component starts later we can still start its dependencies first. But because some modules starts some global components, e.g. by calling {{manager.getCache(name)}}, that assumption breaks.
> The {{infinispan-server-event-logger}} module is a bit more sneaky: it doesn't replace a component, instead it replaces the actual implementation of the event logger in the {{EventLogManager}} component. Events that happen before the module's {{cacheManagerStarting()}} or after {{cacheManagerStopping()}} will be silently dropped from the persistent event log.
> I am investigating making the module a factory of factories. Instead of having a monolitic {{cacheManagerStarting()}} method, it could define a set of components that it can create, and a set of components that should be started before the cache manager is "running". We probably need a way to depend on other modules as well, maybe reusing the {{@Inject}} and {{@ComponentName}} annotations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months