[infinispan-dev] Infinispan URL format

[Dan Berindei]

+1, a URL that gives you a different CacheManager every time you use
it doesn't seem very useful.

JCache also requires the the CacheManager returned for one URL to be
more or less constant:

   * Multiple calls to this method with the same {@link URI} and
   * {@link ClassLoader} must return the same {@link CacheManager} instance,
   * except if a previously returned {@link CacheManager} has been closed.

Cheers
Dan


On Wed, Jun 1, 2016 at 12:29 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> The implementation proposals seem slick, but I'd have some doubts
> about allowing overrides to the datastore settings at this level.
>
> The hot-rod proposal looks fine, as similarly to a RDBMs it helps to
> figure how to connect to a specific database by expressing:
>  - how to reach the DB
>  - WHICH database you mean to connect to
>
> In case of the proposals for Infinispan Embedded, I think we fail
> these goals: you need to provide a means for multiple applications to
> "connect" to the same database. So the container needs to be able to
> distinguish *same* Cache instance from a different one, and this might
> get complex if the URL includes a mixture of client specific settings
> (i.e. how to connect) and configuration of the Cache (i.e. TTL and
> CacheStore options).
> It also gets messy in terms of lifecycle: do you stop the CacheManager
> when the last client is undeployed?
>
> I'd rather see an approach based on naming lookup. How the Cache is
> configured, started and "bound" to that specific name should be
> treated separately.
>
> For that purpose, I think the WildFly caches configuration can be
> considered the first step, and the next would be to allow a "Cache
> configuration fragment" to be deployed either included with an
> application, or independently from an application.
>
> Thanks,
> Sanne
>
>
>
> On 1 June 2016 at 08:24, Tristan Tarrant <ttarrant at redhat.com> wrote:
>> So you've been putting that XSL/Xpath knowledge to good use I see. I
>> like it.
>>
>> Tristan
>>
>> On 01/06/2016 09:02, Radim Vansa wrote:
>>> On 05/31/2016 01:33 PM, Galder Zamarreño wrote:
>>>> Comments inline:
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 30 May 2016, at 09:46, Tristan Tarrant <ttarrant at redhat.com> wrote:
>>>>>
>>>>> In the past there has been talk of representing a connection to
>>>>> Infinispan using a URL, in particular for HotRod.
>>>>> The Hibernate OGM team is now working on adding NoSQL datasources to
>>>>> WildFly, and they've asked for they should represent connections to
>>>>> various of these.
>>>> ^ What's this trying to solve exactly?
>>>>
>>>>> For Hot Rod:
>>>>>
>>>>> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>>>>>
>>>>> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
>>>>> currently support this, so this is forward-looking).
>>>>> Obviously we will support all of the HotRod properties for specifying
>>>>> things like security, etc.
>>>> ^ Hmmm, all properties? Do you envision potentially putting all HR client config inside a URL?
>>>>
>>>>> For Embedded:
>>>>>
>>>>> infinispan:embedded:file://path/to/config.xml (for specifying an
>>>>> external config file)
>>>>> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
>>>>> in JNDI)
>>>>> infinispan:embedded: (configuration specified as properties)
>>>>>
>>>>> For the latter, we also need to be able to represent an infinispan
>>>>> configuration using properties with a simple mapping to XML
>>>>> elements/attributes, e.g.
>>>>>
>>>>> cache-manager.local-cache.mycache.eviction.size=1000
>>>> ^ Why 'local-cache' in property name? cachemanager.mycache...etc would be enough since there can't be duplicate cache names inside a given cache manager. So, is 'local-cache' merely a hint?
>>> The first idea would be to make the left-hand side XPath expressions, so
>>> it would be
>>>
>>> cache-container[@name=myManager].local-cache[@name=myCache].eviction.size=1000
>>>
>>> As we probably want to select only on the name attribute, this could be
>>> sufficient and less verbose:
>>>
>>> cache-container[myManager].local-cache[myCache].eviction.size=1000
>>>
>>> I wouldn't mix 'schema' of the property with user-defined identifiers -
>>> those brackets clearly separate them for good.
>>>
>>> There are cases where you have multiple children in one element - custom
>>> interceptors, groups, persistence (though the current schema tells me I
>>> can have only one store defined)... and there is no clear identifier (as
>>> cache name, or backup site). I would suggest that there a custom
>>> identifier that is not present in configuration would help user identify
>>> this, e.g.
>>>
>>> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].class=org.my.FooStore
>>> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].file=/some/path
>>> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].class=org.my.BarStore
>>> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].url=http://example.com
>>>
>>> My 2c
>>>
>>> Radim
>>>
>>>> Cheers,
>>>>
>>>>> Comments are welcome
>>>>>
>>>>> Tristan
>>>>> --
>>>>> Tristan Tarrant
>>>>> Infinispan Lead
>>>>> JBoss, a division of Red Hat
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev