Quantcast

[infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Galder Zamarreño
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Sebastian Laskawiec
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Gustavo Fernandes-2
In reply to this post by Galder Zamarreño


On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarreño <[hidden email]> 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?

[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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Galder Zamarreño
In reply to this post by Sebastian Laskawiec

--
Galder Zamarreño
Infinispan, Red Hat

> On 6 Apr 2016, at 11:44, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Galder Zamarreño
In reply to this post by Gustavo Fernandes-2

--
Galder Zamarreño
Infinispan, Red Hat

> On 6 Apr 2016, at 12:29, Gustavo Fernandes <[hidden email]> wrote:
>
>
>
> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarreño <[hidden email]> 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?

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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Sanne Grinovero-3
On 6 April 2016 at 15:01, Galder Zamarreño <[hidden email]> wrote:

>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <[hidden email]> wrote:
>>
>>
>>
>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarreño <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Dan Berindei
On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <[hidden email]> wrote:

> On 6 April 2016 at 15:01, Galder Zamarreño <[hidden email]> wrote:
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarreño <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Tristan Tarrant-2


On 06/04/2016 16:57, Dan Berindei wrote:

> On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <[hidden email]> wrote:
>> On 6 April 2016 at 15:01, Galder Zamarreño <[hidden email]> wrote:
>>>
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarreño <[hidden email]> 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).

This was the approach I was going to suggest.

Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Sanne Grinovero-3
In reply to this post by Dan Berindei
On 6 April 2016 at 15:57, Dan Berindei <[hidden email]> wrote:

> On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <[hidden email]> wrote:
>> On 6 April 2016 at 15:01, Galder Zamarreño <[hidden email]> wrote:
>>>
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarreño <[hidden email]> 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).

Yes that's exactly what Hibernate does. The API takes a "Properties"
but people can shovel in other things than just Strings.

>
>>
>> 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.

I didn't mean to suggest JNDI explicitly, just that if you accept
either FQN names in string form or the instance directly, then people
can do anything and including pass in strategies to look up via JNDI
if they prefer to.

>
> 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.

+1

Thanks,
Sanne

>
> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Passing JCache remote manager propietary configuration options (ISPN-6438)

Galder Zamarreño
In reply to this post by Dan Berindei

--
Galder Zamarreño
Infinispan, Red Hat

> On 6 Apr 2016, at 16:57, Dan Berindei <[hidden email]> wrote:
>
> On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <[hidden email]> wrote:
>> On 6 April 2016 at 15:01, Galder Zamarreño <[hidden email]> wrote:
>>>
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarreño <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...