If we go with your approach, there would be little incentive for users to actually fix their application. The problem here is that the "inheritance from the default cache" anti-feature is more often than not the cause of misunderstanding. The real fix is to use configuration templates, obviously.
Tristan On 30/11/16 16:24, Sebastian Laskawiec wrote: > Hey Tristan, > > Comments inlined. > > Thanks > Sebastian > > On Wed, Nov 30, 2016 at 3:13 PM, Tristan Tarrant <ttarr...@redhat.com > <mailto: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/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 > > <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 <mailto: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 > <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 > <mailto:infinispan-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > <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 <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > <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
