On Wed, Nov 30, 2016 at 12:41 PM, Tristan Tarrant <ttarr...@redhat.com> wrote: > On 30/11/16 17:44, Paul Ferraro wrote: >> On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <ttarr...@redhat.com> wrote: >>> Some additional notes: >>> >>> - currently the XSD specifies the default-cache attribute on the >>> cache-container element as required, but the parser doesn't enforce it. >>> - A default ConfigurationBuilder is created for the default cache if one >>> has not been specified >>> >>> My questions: >>> >>> 1. do we want the default cache to be optional or actually require it in >>> the declarative configuration ? >> >> In WildFly, default-cache has been optional since WF8. The >> cache-container used for hibernate 2LC, for example, does not have any >> concept of a default-cache. So, for us anyway, it makes sense for >> default-cache to be optional. However, we have the luxury of falling >> back to Infinispan's default getCache() logic in the event that no >> default-cache was specified. >> >>> ** A: no enforcement. In this case requesting the default cache should >>> print a warning about falling back to a "default" empty configuration. >>> >>> ** B: we don't require the user to specify a default cache in the >>> configuration, but invoking getCache() will throw an exception. >>> >>> ** C: enforce it, although this will break all those XML files who >>> haven't specified it. >>> >>> My preference is to use the namespace version and go for the A approach >>> for < 9.0 and the B approach otherwise. >> >> I think that makes sense. >> >>> 2. currently, requesting a named cache for which a configuration hasn't >>> been defined implicitly creates the cache by using the default >>> configuration as a template. >>> >>> ** A: continue as is >>> >>> ** B: continue to implicitly create a cache, but use an empty >>> configuration instead of using the default configuration, as this has >>> been the source of confusion among users. Also print a warning. >>> >>> ** C: do not create caches unless a configuration has been explicitly >>> provided. >>> >>> My preference is to use the namespace version and go for the A approach >>> for < 9.0 and the C approach otherwise. >> >> Agreed. >> >>> Unfortunately the namespace version trick doesn't work for programmatic >>> configurations. Probably we should add a boolean flag on the >>> GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults >>> to false (because that's the "new order") but allows switching to the >>> old behaviour if needed. >>> >>> In any case I'd like to also introduce a JCache-like createCache() API >> >> I think it would be best/cleanest if caches created via this API are >> anonymous (i.e. not managed by the cache manager or made accessible >> via getCache(String)). That way there is no ambiguity about who is >> meant to manage the lifecycle (user vs container). > > Hmm, this differs from the behaviour of JCache's getCache(String) though.
Yes - and this was one of my biggest complaints about this API. There ought to be a distinction between "managed" caches vs. "ad hoc" caches. This (along with the class loading mess) is one of the reasons why this spec isn't ready for the EE world. >>> Tristan >>> >>> On 10/11/16 13:20, Paul Ferraro wrote: >>>> +1000 >>>> >>>> This is precisely how we've setup cache manager semantics in WildFly >>>> (since AS7): >>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java >>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java >>>> >>>> I'd love to be able to drop this. >>>> >>>> Paul >>>> >>>> On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarr...@redhat.com> >>>> wrote: >>>>> In the discussion for [1] the subject of the default cache and the way >>>>> it affects configuration inheritance came up. >>>>> >>>>> My proposal is: >>>>> - remove the default cache as a special cache altogether >>>>> - CacheManager.getCache() should return the named cache specified as >>>>> default in the configuration. >>>>> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should >>>>> have the notion of the default named cache (currently this is handled in >>>>> the parser) >>>>> - Retrieving the cache named "___defaultcache" should actually retrieve >>>>> the above named cache >>>>> >>>>> Opinions ? >>>>> >>>>> Tristan >>>>> >>>>> [1] https://github.com/infinispan/infinispan/pull/4631 >>>>> -- >>>>> Tristan Tarrant >>>>> Infinispan Lead >>>>> JBoss, a division of 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 >>>> >>> >>> -- >>> Tristan Tarrant >>> Infinispan Lead >>> JBoss, a division of 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 >> > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of 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