Hey Tristan, Comments inlined.
Thanks Sebastian On Wed, Nov 30, 2016 at 3:13 PM, 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 ? > > ** 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 generally don't like the option B, since it frustrates developers and it might make the 8.x -> 9.x migration painful. 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). > > 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. > > 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. > Again A. The same arguments as the above. > > In any case I'd like to also introduce a JCache-like createCache() API > > 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