Mircea, I think the idea was to allow users to create a new CacheManager based on an existing CacheManager, but with some global configuration changes.<br><br>For instance, we could have used it in TestCacheManagerFactory, to allow the user to pass in a GlobalConfiguration instead of a GlobalConfigurationBuilder to when creating CacheManagers. Of course, for us it was easy enough to change all the tests to pass in a GlobalConfigurationBuilder, but I don't really like the caller having to know that the global configuration will be modified before creating the CacheManager.<br>
<br>Cheers<br>Dan<br><br><br><div class="gmail_quote">On Fri, Jul 13, 2012 at 12:02 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mircea.markus@jboss.com" target="_blank">mircea.markus@jboss.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Pete,<br>
<br>
Whilst the 'read(template)' method does make sense in the case of cache level configurations(AbstractConfigurationChildBuilder) in order to override the values from the default cache, is 'read(template)' in the global configuration also needed(AbstractGlobalConfigurationBuilder)? We don't use any override mechanism for global configuration; it also doesn't seem to be used anywhere in the code.<br>
<br>
Cheers,<br>
Mircea<br>
_______________________________________________<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" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div><br>