On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei <dan.berin...@gmail.com> wrote:
> I would go for option 2. > Do you think a WARN message will be enough? I am a bit weary about this option myself. > > We already started disconnecting the cache definition and retrieval, > at least `getCache(name)` doesn't define a new cache based on the > default configuration any more. So I don't think it would be too much, > even at this point, to deprecate all the overloads of `getCache` that > can define a new cache and advise users to use `defineConfiguration` > instead. > Hrmm I like the idea of deprecating the overloads :) > > > > Cheers > Dan > > > On Mon, Feb 27, 2017 at 4:31 PM, William Burns <mudokon...@gmail.com> > wrote: > > When working on another project using Infinispan the code being used was > a > > bit interesting and I don't think our template configuration handling was > > expecting it do so in such a way. > > > > Essentially the code defined a template for a distributed cache as well > as > > some named caches. Then whenever a cache is retrieved it would pass the > > given name and always the distributed cache template. Unfortunately with > > the way templates work they essentially redefine a cache first so the > actual > > cache configuration was wiped out. In this example I was able to get the > > code to change to using a default cache instead, which is the behavior > that > > is needed. > > > > The issue though at hand is whether we should allow a user to call > getCache > > in such a way. My initial thought is to have it throw some sort of > > configuration exception when this is invoked. But there are some possible > > options. > > > > 1. Throw a configuration exception not allowing a user to use a template > > with an already defined cache. This has a slight disconnect between > > configuration and runtime, since if a user adds a new definition it could > > cause runtime issues. > > 2. Log an error/warning message when this occurs. Is this enough though? > > Still could have runtime issues that are possibly undetected. > > 3. Merge the configurations together applying the template first. This > > would be akin to how default cache works currently, but you would get to > > define your default template configuration at runtime. This sounded like > the > > best option to me, but the problem is what if someone calls getCache > using > > the same cache name but a different template. This could get hairy as > well. > > > > Really thinking about the future, disconnecting the cache definition and > > retrieval would be the best option, but we can't do that this late in the > > game. > > > > What do you guys think? > > > > - Will > > > > _______________________________________________ > > 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 >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
