Multiple spring context files (main and test source) duplicate bean references
I've run into this problem quite a bit and I'm curious what is the recommended approach for dealing with it. We have enterprise Maven apps with main and test source packages. We usually have multiple application context files for Spring and sometimes the bean ids are duplicated. A data source bean is an example of such a case where it's defined in the main source context file and the test source context file.
We might have the following in our main context file:
<!-- JNDI DataSource for J2EE environments -->
<jee:jndi-lookup id="dataSource" jndi-name="jdbc/appPool"/>
And a different configuration for tests run outside the container:
<bean id="dataSource" >
<property name="driverClassName" value="${jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
If all the context files are added to a single fileset for the Spring facet we get duplicate bean reference errors in the context files. I tried creating separate main and test filesets for the Spring facet without success. The only option I have found is removing the test context files from the Spring facet fileset and that's not what I want. Are there better options? Thanks.
Grant
Please sign in to leave a comment.
How exactly are you using the test contexts?
The code below should explain it. We load different context files for our tests that just happen to have some common bean IDs with the main context file. My current approach is to exclude these from the Spring facet. It also happens when generating a project template with the Maven app-fuse prototypes.
public abstract class AbstractTestWithContext extends AbstractDependencyInjectionSpringContextTests
{
@Override
protected String[] getConfigLocations()
{
return new String[]{"config/test-applicationContext-hibernate.xml",
"config/test-applicationContext-service.xml"};
}
}
we are doing something close, although not exactly the same.
We create some artifacts (jar files) with some spring based configuration.
However consuming applications may want to override some of this configuration, and they do it by overriding the bean defintions : they create, in their own spring configuration files (which import the framework configuration) bean definitions with the same ids.
Anyway, actually Spring doesn't handle this as an error, it's just IDEA that does, and depending on your own policy/usage this should probably be downgraded to a warning
Good point, I can certainly downgrade it to a warning.