[infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

[Galder Zamarreño]

--
Galder Zamarreño
Infinispan, Red Hat

> On 6 Apr 2016, at 11:44, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
> 
> Option #1 seems reasonable to me (as you mentioned #2 has a lot of limitations). We could use some kind of adapter for this (JCacheManagerAdapter.fromRemoteCacheManager(rcm)). This way we would decouple nice and clean way of creating JCacheManager from the dirty one.

^ You can achieve just that with a static method in JCacheManager, no need for an adapter :|

> 
> After this one is implemented - we could propose an extension to JCache JSR to fabricate JCacheManagers from proprietary managers. I think all vendors should be open for this...

^ Good luck with that, the JSR is now closed and not much seems to be going on.

> 
> 
> On Wed, Apr 6, 2016 at 11:26 AM, Galder Zamarreño <galder at redhat.com> wrote:
> 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
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev