[ https://issues.jboss.org/browse/ISPN-4563?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-4563: ------------------------------------------- The root cause of this bug is in JCacheManager.java: {code} public <K, V, C extends Configuration<K, V>> Cache<K, V> createCache( String cacheName, C configuration) { ... // re-register attempt with different configuration if (cache.getConfiguration(Configuration.class).equals(configuration)) { throw log.cacheAlreadyRegistered(cacheName, cache.getConfiguration(Configuration.class), configuration); } {code} Above code should be replaced by: {code} public <K, V, C extends Configuration<K, V>> Cache<K, V> createCache( String cacheName, C configuration) { ... // re-register attempt with different configuration // Note that configuration should not be equal... if (!cache.getConfiguration(Configuration.class).equals(configuration)) { throw log.cacheAlreadyRegistered(cacheName, cache.getConfiguration(Configuration.class), configuration); } {code} However with this change, JCache testing suite (org.jsr107.tck.CacheManagerTest#getOrCreateCache_Same()) blows out: {code} @Test public void createCache_Same() { String name = "c1"; CacheManager cacheManager = getCacheManager(); try { cacheManager.createCache(name, new MutableConfiguration()); Cache cache1 = cacheManager.getCache(name); cacheManager.createCache(name, new MutableConfiguration()); Cache cache2 = cacheManager.getCache(name); fail(); } catch (CacheException exception) { //expected } } {code} This happens because configurations created by {{new MutableConfiguration()}} are logically equal ({{config1.equals(config2)}}). There are two solutions here: * Compare configurations using {{==}} rather then {{equals}} method (I don't think we should follow this direction). * There is a mistake in JCache testing suite and it should be fixed in the upstream. -- This message was sent by Atlassian JIRA (v6.3.1#6329)