-- Galder Zamarreño Infinispan, Red Hat > On 6 Apr 2016, at 16:57, Dan Berindei <dan.berin...@gmail.com> wrote: > > 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).
^ I had not noticed that! Feels a bit dirty but that'll do :) > >> >> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
