On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > On 6 April 2016 at 15:01, Galder Zamarreño <gal...@redhat.com> wrote: >> >> -- >> Galder Zamarreño >> Infinispan, Red Hat >> >>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <gust...@infinispan.org> wrote: >>> >>> >>> >>> On Wed, Apr 6, 2016 at 10: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? >>> >>> >>> 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.
Our standard configuration API also allows custom implementations that can be provided either as an instance or as a class name. Usually it's the actual implementation, not a factory. The limitation with JSR-107 is that we want it to work with Caching.getCachingProvider().getCacheManager(...), which can take in only a Properties instance and pass that to the cache manager. So far, we assumed all the Properties values must be Strings. However, it looks like Properties extends Hashtable<Object,Object>, so it should be possible to stick any object in there. The only gotcha is that the caller must use Properties.put(k, v) instead of Properties.setProperty(k, v). > > 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. I also suggested JNDI, but I was quickly reminded that JNDI isn't always available, and we don't want to make it a required dependency. We could also have a singleton map for "injectables", and replace JNDI references with keys in our injectables map. Still, I'm always wary about static stuff, so I like the "hack" of storing non-String values in a Properties instance better. Cheers Dan > > 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@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 > > _______________________________________________ > 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
