When bean overriding is on, the same bean appearing twice in an XML stream causes an error [SPR-17649] #22178
I'm filing this report as suggested by snicoll, who says this may be a bug.
I started a discussion because closed issue #13609 caused me a problem that I hadn't seen yet discussed in the context of the issue, or elsewhere. Here is my original comment:
Per his request, I have put together an example. It's the simplest case possible. An XML file includes two XML files that each define a bean. Those beans both depend on a common additional bean, so each of those files includes the same additional XML file, thus causing that XML file to be parsed twice.
Here are those files:
applicationContext.xml <beans ...> <import resource="bean1a.xml"/> <import resource="bean1b.xml"/> </beans> bean1a.xml <beans ...> <import resource="bean1.xml"/> <bean id="testBean1a" class="not.below.app.TestBean"> <constructor-arg value="Hello From TestBean1a!!!"/> <constructor-arg ref="testBean1"/> </bean> </beans> bean1b.xml <beans ...> <import resource="bean1.xml"/> <bean id="testBean1a" class="not.below.app.TestBean"> <constructor-arg value="Hello From TestBean1a!!!"/> <constructor-arg ref="testBean1"/> </bean> </beans> bean1.xml <beans ...> <bean id="testBean1" class="not.below.app.TestBean"> <constructor-arg value="Hello From TestBean1!!!"/> </bean> </beans>
And here's the error stream I get when I run my app:
Now, I didn't get the "APPLICATION FAILED TO START" text before putting together my sample (don't know why...having a spring-boot-web in the mix maybe). This text suggests that I should not expect to get away with defining a bean twice with the same name, even if it's the exact same bean. If that's the case, in contrast to what snicholl said, then maybe I've wasted my time (and that of others) in getting to this point. But...
I'd still like to suggest that if the SAME bean is being redefined...if the same code coordinates are being read a second time...it would be great if this could be ignored. I've had my beans broken up this way for years. There are multiple advantages we get by doing this. I'm not sure I can do anything but turn off the checking for duplicate definitions. I'd much rather have what I'm doing work, but still benefit by getting an error if I'm trying to define two DIFFERENT beans with the same id, or same class type in the case of autowiring or reference by class name.
(I've attached a complete, maven-buildable example)
Reference URL: spring-projects/spring-boot#13609 (comment)
The text was updated successfully, but these errors were encountered:
Sorry, Steve, but I'm going to have to argue against what you are asking. Your issue happens because #5845 was never fixed. If the Spring maintainers want your scenario to work, loading each XML file only once seems like a much better solution.
As is, structuring a Spring project as you prefer can lead to major performance issues (a hole we're trying to dig out of by switching to java config). Therefore, I prefer the error message. Spring loads the bean twice, so it is an override, even though it's the same definition. If Spring would cache the fact that it processed the XML file (similar to how
I would very much like to see #5845 fixed after 13 years, and I believe that would also fix your issue. However, "fixing" this bug without addressing the underlying issue I'm (respectfully) very much against.
Same thing can happen with Java config. For example if you want to use a library with a