We ran into an issue in which we unknowingly had two bean configurations with the same id. Since we are using the simple ClassPathXmlApplicationContext retrieved from a SingletonBeanFactoryLoader, the default behaviour is to override one definition with another. This is not what we want, however, since we use regexp to load our app ctx files from the classpath. We would consider this an issue and would rather spring treated this as a fatal exception on initialization. DefaultListableBeanFactory provides a field allowBeanDefinionOverriding, but this option is not available within the ClassPathXmlApplicationContext.
Can we include the allowBeanDefinitionOverriding="false" option within the ClassPathXmlApplicationContext hiearchy?
#9063 Make AbstractApplicationContext BeanNameAware
The text was updated successfully, but these errors were encountered:
I've added "allowBeanDefinitionOverriding" and "allowCircularReferences" properties to AbstractRefreshableApplicationContext, which ClassPathXmlApplicationContext derives from. Those will be propagated to each underlying DefaultListableBeanFactory.
This fits nicely with ClassPathXmlApplicationContext's new bean-style configuration variant: You can use the default constructor and a "configLocations" property there now, as well as set other properties (such as "allowBeanDefinitionOverriding"), before calling refresh (triggered by ClassPathXmlApplicationContext's new afterPropertiesSet implementation as well).
All of this is going to be available in tonight's 2.5.2 snapshot.
I'm afraid those attributes are not really candidates for the <beans> tag... mainly because they apply to an entire ApplicationContext, not to an isolated bean definition file with a set of bean definitions. Overriding in particular is a characteristic that emerges from loading multiple bean definition files to begin with.
We could support a "contextProperties" attribute analogous to "contextClass", containing key-value pairs of ApplicationContext bean properties... applicable to web.xml-driven setup. For beanRefContext.xml-style setup, those properties are easy enough to set via standard <property> elements. And for programmatic setup, they can obviously be called directly.
Shouldn't setAllowBeanDefinitionOverriding() method be promoted to ConfigurableWebApplicationContext interface?
I'm trying to subclass ContextLoaderListener and ContextLoader so that they set the allowBeanDefinitionOverriding property on the web application context being created, but customizeContext method accepts ConfigurableWebApplicationContext as parameter.
So currently a cast to AbstractRefreshableApplicationContext is needed.