[infinispan-issues] [JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used

[Tristan Tarrant (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tristan Tarrant updated ISPN-6574:
----------------------------------
           Status: Resolved  (was: Pull Request Sent)
    Fix Version/s: 8.2.2.Final
       Resolution: Done


> JCache CacheManger need to know about existing caches if remote (HotRod) is used
> --------------------------------------------------------------------------------
>
>                 Key: ISPN-6574
>                 URL: https://issues.jboss.org/browse/ISPN-6574
>             Project: Infinispan
>          Issue Type: Bug
>          Components: JCache
>    Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Galder Zamarreño
>             Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final
>
>
> For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
> Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
> Excerpt from API Doc:
> ------------------------------------
> K,V> Cache<K,V> getCache(String cacheName,
>                         Class<K> keyType,
>                         Class<V> valueType)
> Looks up a managed Cache given its name.
> This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
> Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
> Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
> Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
> Parameters:
>     cacheName - the name of the managed Cache to acquire
>     keyType - the expected Class of the key
>     valueType - the expected Class of the value
> Returns:
>     the Cache or null if it does exist or can't be pre-configured
> Throws:
>     IllegalStateException - if the CacheManager is isClosed()
>     IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
>     SecurityException - when the operation could not be performed due to the current security settings



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)