Make it easier to disallow bean definition overriding [SPR-3734]

[spring-projects-issues]

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

---

<import resource="file2.xml"/>
<bean id="foo1" name="foo1" class="foo.Foo"><property name="echo" value="1"/></bean>

---

File 2(file2.xml)

---

<bean id="foo1" name="foo1" class="foo.Foo"><property name="echo" value="1"/></bean>

---

---

Affects: 2.0.6

Attachments:

• Spring.zip (2.97 kB)

Issue Links:

• Circular dependence forbidding cannot be easily configured. [SPR-2048] #6741 Circular dependence forbidding cannot be easily configured.

2 votes, 2 watchers

[spring-projects-issues]

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

[spring-projects-issues]

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.

[spring-projects-issues]

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.

ApplicationContext factory = new ClassPathXmlApplicationContext(
		"application.xml") {
	protected DefaultListableBeanFactory createBeanFactory() {
		final DefaultListableBeanFactory vResult = super
				.createBeanFactory();
		vResult.setAllowBeanDefinitionOverriding(false);
		return vResult;
	}
};

[spring-projects-issues]

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();
context.setAllowBeanDefinitionOverriding(false);
context.load("myResource.xml", "otherResource.xml");
context.refresh();

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