Hi all,
I've been looking at [1] and the way I see it, there are two ways to solve this:
1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances
using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One
way to solve this issue would be if we exposed a propietary way to create an Infinispan
remote JCacheManager, e.g.
new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
...etc, or similar solutions
The problem with this approach is that we force users to create JCacheManager instances
using implementation detail APIs.
2. The only way you can pass in implementation specific configuration options to
JCacheManager instances using standard APIs is via a Properties file. So, the other
solution is to have the missing client configuration options available as being able to
configure them via Properties. The main limitation here is that property values must be
String values. According to Tristan, this could limit some security configuration for
options that can be converted into String values. Looking at
org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration
option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I
don't see the sslContext() method used anywhere...? The rest of SSL options take
either a String or char[] so those would not be problematic.
Thoughts?
[1]
https://issues.jboss.org/browse/ISPN-6438
--
Galder Zamarreño
Infinispan, Red Hat