-
Notifications
You must be signed in to change notification settings - Fork 37.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it easier to disallow bean definition overriding [SPR-3734] #8415
Comments
Juergen Hoeller commented This is an expected consequence of bean definition overriding. 'Later' bean definitions are allowed to override 'earlier' bean definitions, referring to the order of loading the bean definition files. This only applies to separate bean definition files, though: e.g. a context config location consisting of multiple files or the use of imports. Note that there will be info log messages for any such overridden bean definition. I would recommend to keep 'info' level active in your log configuration in order to see such stuff. You can turn the entire overriding off by calling "setAllowBeanDefinitionOverriding(false)" on your DefaultListableBeanFactory, which of course is only straightforward when you programmatically bootstrap your ApplicationContext (e.g. a GenericApplicationContext). We'll see what we can do about this for Spring 3.0, probably even changing the default. Juergen |
Moritz Kleine commented I prefer not to change the default bean definition overriding behavior. I know quite a lot of spring based applications that use this feature for extensibility reasons: An application context is created that uses a location pattern like /default/.xml and /custom/.xml. This allows users to override default bean definitions without touching any of the application's files. If the default behavior has to be changed, there should at least be an easy way to restore the old (current) behavior. Summary: This comment is meant to be a no-vote. |
Trent Andrews commented I would just like an option(An additional Argument) to send into the ApplicationContext constructors. Just in case anyone needs to turn this off right now.
|
Juergen Hoeller commented setAllowCircularReferences and setAllowBeanDefinitionOverriding are available on GenericApplicationContext now, as well as on a new GenericXmlApplicationContext that should preferably be used over ClassPath/FileSystemXmlApplicationContext. The typical usage model looks like as follows: GenericXmlApplicationContext context = new GenericXmlApplicationContext(); Similar to the existing GenericApplicationContext plus XmlBeanDefinitionReader approach, just with everything combined into a one-stop shop. FYI, there is a new AnnotationConfigApplicationContext as well now: providing the same style for classpath scanning. Juergen |
Trent Andrews opened SPR-3734 and commented
If you have two beans in the same xml(Example 1) file spring will detect that you have two beans with the same name and throw XmlBeanDefinitionStoreException
===== Example 1 =====
<bean id="foo1" class="foo.Foo"><property name="echo" value="1"/></bean>
<bean id="foo1" class="foo.Foo"><property name="echo" value="2"/></bean>
But if you import one xml file into another it does not see the problem and I believe that it should.
==== Example 2 ====
File 1
File 2(file2.xml)
Affects: 2.0.6
Attachments:
Issue Links:
2 votes, 2 watchers
The text was updated successfully, but these errors were encountered: