-- Galder Zamarreño Infinispan, Red Hat > On 6 Apr 2016, at 11:44, Sebastian Laskawiec <slask...@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 <gal...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
