<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll see if I can work around it, but I was aware I did it. I thought that they did document "last one wins" somewhere, but if not I agree I should find another way.<br></blockquote><div><br></div><div>It's documented, though not as prominently as you might like:</div><div><br></div><div><a href="http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/support/DefaultListableBeanFactory.html#setAllowBeanDefinitionOverriding-boolean-">http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/support/DefaultListableBeanFactory.html#setAllowBeanDefinitionOverriding-boolean-</a></div><div><br></div><div>That feels like an implementation detail instead of a contract, but as Ian said it's been that way forever and probably won't change. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My opinion is we should avoid the technique unless it substantially improves *user* level configuration of something.<br></blockquote><div><br></div><div>Allowing user-space configuration files to contain bean definitions that override system bean definitions is an incredibly useful feature for extension. We should support it in some fashion if not use it outright ourselves.</div><div><br></div><div>M</div><div><br></div></div></div>