<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 27, 2017 at 9:50 AM Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While we could define the behaviour as in 3), I think that this is most<br class="gmail_msg"></blockquote><div><br></div><div>Yeah rereading what I wrote again, it was definitely misleading. 3) was what I wanted when I first found the issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
likely a configuration error. Therefore, I'd go with 1), and ideally<br class="gmail_msg"></blockquote><div><br></div><div>That is what I was leaning towards as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
provide a link to FAQ/docs where you'd explain what exactly happened in<br class="gmail_msg">
the exception message.<br class="gmail_msg"></blockquote><div><br></div><div>Yeah I will make sure we have some stuff added to the template section of the user guide.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
R.<br class="gmail_msg">
<br class="gmail_msg">
On 02/27/2017 03:31 PM, William Burns wrote:<br class="gmail_msg">
> When working on another project using Infinispan the code being used<br class="gmail_msg">
> was a bit interesting and I don't think our template configuration<br class="gmail_msg">
> handling was expecting it do so in such a way.<br class="gmail_msg">
><br class="gmail_msg">
> Essentially the code defined a template for a distributed cache as<br class="gmail_msg">
> well as some named caches. Then whenever a cache is retrieved it would<br class="gmail_msg">
> pass the given name and always the distributed cache template.<br class="gmail_msg">
> Unfortunately with the way templates work they essentially redefine a<br class="gmail_msg">
> cache first so the actual cache configuration was wiped out. In this<br class="gmail_msg">
> example I was able to get the code to change to using a default cache<br class="gmail_msg">
> instead, which is the behavior that is needed.<br class="gmail_msg">
><br class="gmail_msg">
> The issue though at hand is whether we should allow a user to call<br class="gmail_msg">
> getCache in such a way. My initial thought is to have it throw some<br class="gmail_msg">
> sort of configuration exception when this is invoked. But there are<br class="gmail_msg">
> some possible options.<br class="gmail_msg">
><br class="gmail_msg">
> 1. Throw a configuration exception not allowing a user to use a<br class="gmail_msg">
> template with an already defined cache. This has a slight disconnect<br class="gmail_msg">
> between configuration and runtime, since if a user adds a new<br class="gmail_msg">
> definition it could cause runtime issues.<br class="gmail_msg">
> 2. Log an error/warning message when this occurs. Is this enough<br class="gmail_msg">
> though? Still could have runtime issues that are possibly undetected.<br class="gmail_msg">
> 3. Merge the configurations together applying the template first.<br class="gmail_msg">
> This would be akin to how default cache works currently, but you would<br class="gmail_msg">
> get to define your default template configuration at runtime. This<br class="gmail_msg">
> sounded like the best option to me, but the problem is what if someone<br class="gmail_msg">
> calls getCache using the same cache name but a different template.<br class="gmail_msg">
> This could get hairy as well.<br class="gmail_msg">
><br class="gmail_msg">
> Really thinking about the future, disconnecting the cache definition<br class="gmail_msg">
> and retrieval would be the best option, but we can't do that this late<br class="gmail_msg">
> in the game.<br class="gmail_msg">
><br class="gmail_msg">
> What do you guys think?<br class="gmail_msg">
><br class="gmail_msg">
> - Will<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> infinispan-dev mailing list<br class="gmail_msg">
> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Radim Vansa <<a href="mailto:rvansa@redhat.com" class="gmail_msg" target="_blank">rvansa@redhat.com</a>><br class="gmail_msg">
JBoss Performance Team<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
infinispan-dev mailing list<br class="gmail_msg">
<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
</blockquote></div></div>