<div dir="ltr">Hi<br><div class="gmail_extra"><br><div class="gmail_quote">2017-02-28 22:51 GMT+01:00 William Burns <span dir="ltr"><<a href="mailto:mudokonman@gmail.com" target="_blank">mudokonman@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>So while I was trying to work on this, I have to admit I am even more torn in regards to what to do. Looking at [1] it looks like the template should only be applied if the cache configuration is not currently defined. Unfortunately it doesn't work this way and always applies this template to any existing configuration. So I am thinking an alternative is to instead make it work as the documentation states, only using the template if the cache is not currently defined. This seems more logical to me at least.<br></div></div></div></blockquote><div><br></div><div>I guess you started this conversation because of the issue you found in vertx-infinispan :) Then yes, when I used this method the Javadoc made me think that the template would be picked if no cache with the provided name exists.</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"><div dir="ltr"><div><div><br></div>With that change the getCache(String, String) could stay as long as it is documented that a template is only applied if no cache configuration exists.<br><br></div><span class="gmail-">What do you guys think?<br></span></div></blockquote><div><br></div><div><br class="gmail-Apple-interchange-newline">Sounds better to me since it's what the doc suggests.<br></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"><div dir="ltr"><span class="gmail-"></span><div><div><br>[1] <a href="https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84" target="_blank">https://github.com/infinispan/<wbr>infinispan/blob/master/core/<wbr>src/main/java/org/infinispan/<wbr>manager/EmbeddedCacheManager.<wbr>java#L84</a><div><div class="gmail-h5"><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 27, 2017 at 10:09 AM William Burns <<a href="mailto:mudokonman@gmail.com" target="_blank">mudokonman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_4362864274553905948gmail_msg"><div class="gmail_quote gmail-m_4362864274553905948gmail_msg"><div dir="ltr" class="gmail-m_4362864274553905948gmail_msg">On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei <<a href="mailto:dan.berindei@gmail.com" class="gmail-m_4362864274553905948gmail_msg" target="_blank">dan.berindei@gmail.com</a>> wrote:<br class="gmail-m_4362864274553905948gmail_msg"></div><blockquote class="gmail_quote gmail-m_4362864274553905948gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would go for option 2.<br class="gmail-m_4362864274553905948gmail_msg"></blockquote><div class="gmail-m_4362864274553905948gmail_msg"><br class="gmail-m_4362864274553905948gmail_msg"></div></div></div><div dir="ltr" class="gmail-m_4362864274553905948gmail_msg"><div class="gmail_quote gmail-m_4362864274553905948gmail_msg"><div class="gmail-m_4362864274553905948gmail_msg">Do you think a WARN message will be enough? I am a bit weary about this option myself.</div></div></div><div dir="ltr" class="gmail-m_4362864274553905948gmail_msg"><div class="gmail_quote gmail-m_4362864274553905948gmail_msg"><div class="gmail-m_4362864274553905948gmail_msg"> </div><blockquote class="gmail_quote gmail-m_4362864274553905948gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="gmail-m_4362864274553905948gmail_msg">
We already started disconnecting the cache definition and retrieval,<br class="gmail-m_4362864274553905948gmail_msg">
at least `getCache(name)` doesn't define a new cache based on the<br class="gmail-m_4362864274553905948gmail_msg">
default configuration any more. So I don't think it would be too much,<br class="gmail-m_4362864274553905948gmail_msg">
even at this point, to deprecate all the overloads of `getCache` that<br class="gmail-m_4362864274553905948gmail_msg">
can define a new cache and advise users to use `defineConfiguration`<br class="gmail-m_4362864274553905948gmail_msg">
instead.<br class="gmail-m_4362864274553905948gmail_msg"></blockquote><div class="gmail-m_4362864274553905948gmail_msg"><br class="gmail-m_4362864274553905948gmail_msg"></div></div></div><div dir="ltr" class="gmail-m_4362864274553905948gmail_msg"><div class="gmail_quote gmail-m_4362864274553905948gmail_msg"><div class="gmail-m_4362864274553905948gmail_msg">Hrmm I like the idea of deprecating the overloads :)</div></div></div><div dir="ltr" class="gmail-m_4362864274553905948gmail_msg"><div class="gmail_quote gmail-m_4362864274553905948gmail_msg"><div class="gmail-m_4362864274553905948gmail_msg"> </div><blockquote class="gmail_quote gmail-m_4362864274553905948gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="gmail-m_4362864274553905948gmail_msg">
<br class="gmail-m_4362864274553905948gmail_msg">
<br class="gmail-m_4362864274553905948gmail_msg">
Cheers<br class="gmail-m_4362864274553905948gmail_msg">
Dan<br class="gmail-m_4362864274553905948gmail_msg">
<br class="gmail-m_4362864274553905948gmail_msg">
<br class="gmail-m_4362864274553905948gmail_msg">
On Mon, Feb 27, 2017 at 4:31 PM, William Burns <<a href="mailto:mudokonman@gmail.com" class="gmail-m_4362864274553905948gmail_msg" target="_blank">mudokonman@gmail.com</a>> wrote:<br class="gmail-m_4362864274553905948gmail_msg">
> When working on another project using Infinispan the code being used was a<br class="gmail-m_4362864274553905948gmail_msg">
> bit interesting and I don't think our template configuration handling was<br class="gmail-m_4362864274553905948gmail_msg">
> expecting it do so in such a way.<br class="gmail-m_4362864274553905948gmail_msg">
><br class="gmail-m_4362864274553905948gmail_msg">
> Essentially the code defined a template for a distributed cache as well as<br class="gmail-m_4362864274553905948gmail_msg">
> some named caches. Then whenever a cache is retrieved it would pass the<br class="gmail-m_4362864274553905948gmail_msg">
> given name and always the distributed cache template. Unfortunately with<br class="gmail-m_4362864274553905948gmail_msg">
> the way templates work they essentially redefine a cache first so the actual<br class="gmail-m_4362864274553905948gmail_msg">
> cache configuration was wiped out. In this example I was able to get the<br class="gmail-m_4362864274553905948gmail_msg">
> code to change to using a default cache instead, which is the behavior that<br class="gmail-m_4362864274553905948gmail_msg">
> is needed.<br class="gmail-m_4362864274553905948gmail_msg">
><br class="gmail-m_4362864274553905948gmail_msg">
> The issue though at hand is whether we should allow a user to call getCache<br class="gmail-m_4362864274553905948gmail_msg">
> in such a way. My initial thought is to have it throw some sort of<br class="gmail-m_4362864274553905948gmail_msg">
> configuration exception when this is invoked. But there are some possible<br class="gmail-m_4362864274553905948gmail_msg">
> options.<br class="gmail-m_4362864274553905948gmail_msg">
><br class="gmail-m_4362864274553905948gmail_msg">
> 1. Throw a configuration exception not allowing a user to use a template<br class="gmail-m_4362864274553905948gmail_msg">
> with an already defined cache. This has a slight disconnect between<br class="gmail-m_4362864274553905948gmail_msg">
> configuration and runtime, since if a user adds a new definition it could<br class="gmail-m_4362864274553905948gmail_msg">
> cause runtime issues.<br class="gmail-m_4362864274553905948gmail_msg">
> 2. Log an error/warning message when this occurs. Is this enough though?<br class="gmail-m_4362864274553905948gmail_msg">
> Still could have runtime issues that are possibly undetected.<br class="gmail-m_4362864274553905948gmail_msg">
> 3. Merge the configurations together applying the template first. This<br class="gmail-m_4362864274553905948gmail_msg">
> would be akin to how default cache works currently, but you would get to<br class="gmail-m_4362864274553905948gmail_msg">
> define your default template configuration at runtime. This sounded like the<br class="gmail-m_4362864274553905948gmail_msg">
> best option to me, but the problem is what if someone calls getCache using<br class="gmail-m_4362864274553905948gmail_msg">
> the same cache name but a different template. This could get hairy as well.<br class="gmail-m_4362864274553905948gmail_msg">
><br class="gmail-m_4362864274553905948gmail_msg">
> Really thinking about the future, disconnecting the cache definition and<br class="gmail-m_4362864274553905948gmail_msg">
> retrieval would be the best option, but we can't do that this late in the<br class="gmail-m_4362864274553905948gmail_msg">
> game.<br class="gmail-m_4362864274553905948gmail_msg">
><br class="gmail-m_4362864274553905948gmail_msg">
> What do you guys think?<br class="gmail-m_4362864274553905948gmail_msg">
><br class="gmail-m_4362864274553905948gmail_msg">
> - Will<br class="gmail-m_4362864274553905948gmail_msg">
><br class="gmail-m_4362864274553905948gmail_msg">
> ______________________________<wbr>_________________<br class="gmail-m_4362864274553905948gmail_msg">
> infinispan-dev mailing list<br class="gmail-m_4362864274553905948gmail_msg">
> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail-m_4362864274553905948gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail-m_4362864274553905948gmail_msg">
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail-m_4362864274553905948gmail_msg" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br class="gmail-m_4362864274553905948gmail_msg">
______________________________<wbr>_________________<br class="gmail-m_4362864274553905948gmail_msg">
infinispan-dev mailing list<br class="gmail-m_4362864274553905948gmail_msg">
<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail-m_4362864274553905948gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail-m_4362864274553905948gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail-m_4362864274553905948gmail_msg" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br class="gmail-m_4362864274553905948gmail_msg">
</blockquote></div></div></blockquote></div></div></div></div></div></div></div>
<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></blockquote></div><br></div></div>