<div dir="ltr">Hey Tristan,<div><br></div><div>Comments inlined.</div><div><br></div><div>Thanks</div><div>Sebastian</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 30, 2016 at 3:13 PM, Tristan Tarrant <span dir="ltr"><<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Some additional notes:<br>
<br>
- currently the XSD specifies the default-cache attribute on the<br>
cache-container element as required, but the parser doesn't enforce it.<br>
- A default ConfigurationBuilder is created for the default cache if one<br>
has not been specified<br>
<br>
My questions:<br>
<br>
1. do we want the default cache to be optional or actually require it in<br>
the declarative configuration ?<br>
<br>
** A: no enforcement. In this case requesting the default cache should<br>
print a warning about falling back to a "default" empty configuration.<br>
<br>
** B: we don't require the user to specify a default cache in the<br>
configuration, but invoking getCache() will throw an exception.<br>
<br>
** C: enforce it, although this will break all those XML files who<br>
haven't specified it.<br>
<br>
My preference is to use the namespace version and go for the A approach<br>
for < 9.0 and the B approach otherwise.<br></blockquote><div><br></div><div>I generally don't like the option B, since it frustrates developers and it might make the 8.x -> 9.x migration painful.</div><div><br></div><div>However I really like your proposal for a GlobalConfigurationManager with implicitCacheCreation. However I would set it to true as our default. Effectively this would results in option A being implemented (somewhat).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2. currently, requesting a named cache for which a configuration hasn't<br>
been defined implicitly creates the cache by using the default<br>
configuration as a template.<br>
<br>
** A: continue as is<br>
<br>
** B: continue to implicitly create a cache, but use an empty<br>
configuration instead of using the default configuration, as this has<br>
been the source of confusion among users. Also print a warning.<br>
<br>
** C: do not create caches unless a configuration has been explicitly<br>
provided.<br>
<br>
My preference is to use the namespace version and go for the A approach<br>
for < 9.0 and the C approach otherwise.<br>
<br>
Unfortunately the namespace version trick doesn't work for programmatic<br>
configurations. Probably we should add a boolean flag on the<br>
GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults<br>
to false (because that's the "new order") but allows switching to the<br>
old behaviour if needed.<br></blockquote><div><br></div><div>Again A. The same arguments as the above.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In any case I'd like to also introduce a JCache-like createCache() API<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Tristan<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On 10/11/16 13:20, Paul Ferraro wrote:<br>
> +1000<br>
><br>
> This is precisely how we've setup cache manager semantics in WildFly<br>
> (since AS7):<br>
> <a href="https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java" rel="noreferrer" target="_blank">https://github.com/wildfly/<wbr>wildfly/blob/master/<wbr>clustering/infinispan/spi/src/<wbr>main/java/org/wildfly/<wbr>clustering/infinispan/spi/<wbr>CacheContainer.java</a><br>
> <a href="https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java" rel="noreferrer" target="_blank">https://github.com/wildfly/<wbr>wildfly/blob/master/<wbr>clustering/infinispan/<wbr>extension/src/main/java/org/<wbr>jboss/as/clustering/<wbr>infinispan/<wbr>DefaultCacheContainer.java</a><br>
><br>
> I'd love to be able to drop this.<br>
><br>
> Paul<br>
><br>
> On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br>
>> In the discussion for [1] the subject of the default cache and the way<br>
>> it affects configuration inheritance came up.<br>
>><br>
>> My proposal is:<br>
>> - remove the default cache as a special cache altogether<br>
>> - CacheManager.getCache() should return the named cache specified as<br>
>> default in the configuration.<br>
>> - the programmatic GlobalConfigurationBuilder/<wbr>GlobalConfiguration should<br>
>> have the notion of the default named cache (currently this is handled in<br>
>> the parser)<br>
>> - Retrieving the cache named "___defaultcache" should actually retrieve<br>
>> the above named cache<br>
>><br>
>> Opinions ?<br>
>><br>
>> Tristan<br>
>><br>
>> [1] <a href="https://github.com/infinispan/infinispan/pull/4631" rel="noreferrer" target="_blank">https://github.com/infinispan/<wbr>infinispan/pull/4631</a><br>
>> --<br>
>> Tristan Tarrant<br>
>> Infinispan Lead<br>
>> JBoss, a division of Red Hat<br>
>> ______________________________<wbr>_________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br>
> ______________________________<wbr>_________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br>
><br>
<br>
--<br>
Tristan Tarrant<br>
Infinispan Lead<br>
JBoss, a division of Red Hat<br>
______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br>
</div></div></blockquote></div><br></div></div>