Understanding config sets

[plethora]

My project context files are organized like this:
-applicationContext.xml: generic bean definition (not infrastructure dependent)
-envProduction.xml: datasource/transactionmanager/mailserver for production environment
-envStaging.xml: datasource/transactionmanager/mailserver for staging environment

These context files can be combined into two different meaningful sets:
-envProduction.xml + applicationContext.xml -> complete production environment
-envStaging.xml + applicationContext.xml -> complete staging environment

How should I map this onto the "config set" abstraction of SpringIde?
I assume I can create two config sets, one for production, another one for staging.
But the thing I'm looking for is a "Set as Current" option for a config set.

Otherwise I'll end up with duplicate bean ids in the "combined set". (both envProduction and envStaging define a transaction manager, for instance)

[momania]

What I usually do is use the PropertyPlaceholderConfigurer

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
		p:location="${system.env.pointing.to.property.file}"/>

This way, you don't need to have different configuration xml files for each environment. Environment specific settings can be placed in the property file and for each environment you have a different property file (that is not part of your deployment)

[Torsten Juergeleit]

These context files can be combined into two different meaningful sets:

-envProduction.xml + applicationContext.xml -> complete production environment
-envStaging.xml + applicationContext.xml -> complete staging environment

How should I map this onto the "config set" abstraction of SpringIde?

You already described the corresponding BeansConfigSets and their names :-)

I assume I can create two config sets, one for production, another one for staging.
But the thing I'm looking for is a "Set as Current" option for a config set.

There's no need for a "current option". Spring IDE doesn't care about the usage of the config files within a Spring application. The notion of "config set" was introduced to combine different config files into a single Spring BeanFactory or ApplicationContext for Spring IDE's validation and visualization (BeansGraph) support only.

Otherwise I'll end up with duplicate bean ids in the "combined set". (both envProduction and envStaging define a transaction manager, for instance)

No, within the different config sets (as within your different ApplicationContexts during runtime) are no duplicate bean ids. Otherwise you would run into problems during runtime.