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.
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...
On Wed, Apr 6, 2016 at 11:26 AM, Galder Zamarreño <galder(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev