4:27 p.m.
On 6 April 2016 at 15:01, Galder Zamarreño <galder(a)redhat.com> wrote:
--
Galder Zamarreño
Infinispan, Red Hat
> On 6 Apr 2016, at 12:29, Gustavo Fernandes <gustavo(a)infinispan.org> wrote:
>
>
>
> On Wed, Apr 6, 2016 at 10: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?
>
>
> Regardless of JCache, I think a HotRod client should be configurable via properties
only (this is needed for [2]) as described in [1], maybe we could introduce factories for
non-String based configs?
Interesting idea about using factories for non-String configs but not sure that will
work? I mean, you'd provide the FQN of the factory class, which would be instantiated
with reflection an an empty constructor. What about if that factory relied on some kind of
initialization? IOW, if the thing you're building comes from something else?
+1 to stick to use only properties for Hot Rod so I can embed them all
in configuration files for Hibernate OGM ;)
In Hibernate it's common to allow passing such a factory within the
configuration Map.
If the value of the properties map is a String, then it's interpreted
as a FQN and started via reflection; if it's not a String it verifies
that it is an _instance_ of the required contract, and takes the
instance as is. So integrating frameworks can inject more complex
stuff by simple reference.
That's for example how WildFly injects stuff into Hibernate ORM to use
in most cases; in some cases it still uses the "old style" approach of
defining a jndi lookup convention, but most such JNDI names area also
injected, if it's not injecting the "lookup strategy" by FQN: having
both gives you lots of flexibility.
Thanks,
Sanne
I don't know the SSLContext use case enough to know if your suggestion would work.
Maybe @Tristan can chime in?
Cheers,
>
> [2] https://issues.jboss.org/browse/ISPRK-16
>
>
> Gustavo
>
>
>
> [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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev