[JBoss JIRA] (ISPN-11860) Wrong Javadoc for state-transfer configuration
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11860?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11860:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 11.0.0.CR1
Resolution: Done
> Wrong Javadoc for state-transfer configuration
> ----------------------------------------------
>
> Key: ISPN-11860
> URL: https://issues.redhat.com/browse/ISPN-11860
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Priority: Trivial
> Fix For: 11.0.0.CR1
>
>
> The XSD only allow replicated- distributed- and scattered-cache to configure state-transfer.
> But the class header is like followed
> /**
> * Configures how state is retrieved when a new cache joins the cluster.
> * Used with invalidation and replication clustered modes.
> *
> * @since 5.1
> */
> public class StateTransferConfiguration implements Matchable<StateTransferConfiguration>, ConfigurationInfo {
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11865) Deprecate the @Store annotation
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-11865:
-----------------------------------
Summary: Deprecate the @Store annotation
Key: ISPN-11865
URL: https://issues.redhat.com/browse/ISPN-11865
Project: Infinispan
Issue Type: Enhancement
Reporter: Ryan Emerson
Assignee: Ryan Emerson
The {{@Store}} annotation was originally added in 9.0 to allow store capabilities to be defined without having to utilise yet another interface, however other than for {{shared}} stores this was never utilised.
The new SPI introduced Characteristics that make this annotation redundant, therefore we should deprecate and remove in Infinispan 14.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11863) Deprecate ClusterLoader and LocalOnlyCacheLoader.
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-11863:
-----------------------------------
Summary: Deprecate ClusterLoader and LocalOnlyCacheLoader.
Key: ISPN-11863
URL: https://issues.redhat.com/browse/ISPN-11863
Project: Infinispan
Issue Type: Task
Components: Core, Loaders and Stores
Affects Versions: 11.0.0.Dev05
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 11.0.0.CR1
The `ClusterLoader` is not documented and is never used as it's unpredictable and has several race conditions, we should deprecate and remove in Infinispan 14.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11862) Remove CacheStoreFactoryRegistry
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11862?page=com.atlassian.jira.plugi... ]
Ryan Emerson reassigned ISPN-11862:
-----------------------------------
Assignee: Ryan Emerson
> Remove CacheStoreFactoryRegistry
> --------------------------------
>
> Key: ISPN-11862
> URL: https://issues.redhat.com/browse/ISPN-11862
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Dev05
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> We should remove {{CacheStoreFactoryRegistry}} as its original use was to allow for custom store implementations that were deployed to the Wildfly server, however as the new server does not allow runtime deployments this abstraction only adds unnecessary complexity to core.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11862) Remove CacheStoreFactoryRegistry
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-11862:
-----------------------------------
Summary: Remove CacheStoreFactoryRegistry
Key: ISPN-11862
URL: https://issues.redhat.com/browse/ISPN-11862
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 11.0.0.Dev05
Reporter: Ryan Emerson
Fix For: 11.0.0.Final
We should remove {{CacheStoreFactoryRegistry}} as its original use was to allow for custom store implementations that were deployed to the Wildfly server, however as the new server does not allow runtime deployments this abstraction only adds unnecessary complexity to core.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11642) Remote JCacheManager doesn't apply configuration from URI
by Nathan Mittlestat (Jira)
[ https://issues.redhat.com/browse/ISPN-11642?page=com.atlassian.jira.plugi... ]
Nathan Mittlestat commented on ISPN-11642:
------------------------------------------
Hi Tristan. Thanks for the update. To follow up, is there a plan to support cache names with "." in them? Also, can we apply a generic template as the example shows or globally to all caches created through a hotrod client? i.e. `<replicated-cache-configuration name="com.myproject.*"/>`.
Finally, our use case involves creating/deleting caches as applications are deployed/undeployed. Can we dynamically update a CacheManager's vendorProperties? Or would we be required to create a new CacheManager every time we want to add a new cache? We don't know what caches will be created at the time the CacheManager is initialized. That is why we have been trying to apply config like this:
```xml
<infinispan>
<cache-container>
<replicated-cache-configuration name="com.myproject.*"/>
</cache-container>
</infinispan>
```
Thank you for your help as always.
> Remote JCacheManager doesn't apply configuration from URI
> ---------------------------------------------------------
>
> Key: ISPN-11642
> URL: https://issues.redhat.com/browse/ISPN-11642
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 10.1.6.Final
> Reporter: Nathan Mittlestat
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.1.7.Final, 11.0.0.Dev05
>
>
> Our project is using JCache API's backed by Infinspan. This is a client-server scenario where we are configuring the Hot Rod Java Client to connect to an Infinispan server.
> We are using _javax.cache.spi.CachingProvider.getCacheManager(URI, ClassLoader, Properties)_ to obtain a _CacheManager_. The URI passed points to an infinispan XML that specifies replicated-cache-configuration as part of the configuration. However the cache created from _CacheManager.createCache()_ ends up being a local cache. This proves to be a problem when connecting to a cluster of Infinispan servers, as when other connections attempt to utilize the cached data, they connect to a different Infinispn sever that doesn't have the cached data. We have verified the XML file pointed to by the URI is on the ClassLoader passed to the _CacheManager_, and still see the same results.
> When we attempt this same scenario using embedded mode instead of client server mode, the configuration in the URI is applied correctly. We have even been able to create a cluster of embedded Infinispan servers via JGroups and confirmed the caches are replicated and not local.
> We have also attempted this scenario using Infinispan's proprietary APIs:
> _RemoteCacheManager.administration().getOrCreateCache(String name, BasicConfiguration configuration)_
> The configuration object passed to _RemoteCacheManagerAdmin.getOrCreateCache()_ loads the same Infinispan XML configuration used in the failing remote JCache scenario (as a _XMlStringConfiguration_ object).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months