[#SPR-1358] ${...} placeholders support for import only works on system properties

Spring Framework

${...} placeholders support for import only works on system properties

Created: 06/Oct/05 01:43 PM Updated: 11/Sep/08 05:59 PM

Component/s:

SpringCORE

Affects Version/s:

1.2.6

Fix Version/s:

None

Time Tracking:

Not Specified

Environment:

Virtual Machine:	Sun JVM - 1.4.2
Platform:	Tomcat - 4.1

Description

« Hide

Please see comments on ~~SPR-1332~~ for more information

All

Comments

Work Log

Change History

FishEye

Builds

Sort Order:

[ Permalink | « Hide ]

Juergen Hoeller added a comment - 07/Oct/05 07:44 AM

This is by design. Imports are processed before any beans get instantiated, even before BeanFactoryPostProcessors such as PropertyPlaceholderConfigurer. Hence, placeholders in import locations cannot be resolved by a PropertyPlaceholderConfigurer, at least not without a major change in the BeanFactory architecture.

Juergen

[ Permalink | « Hide ]

Alex Wei added a comment - 01/Aug/06 01:14 AM

An EagerPropertyPlaceholderConfigurer coud provide the required function. Please see the related issue:
http://opensource.atlassian.com/projects/spring/browse/SPR-1076

[ Permalink | « Hide ]

Ian Brandt added a comment - 11/Sep/08 05:59 PM

Any chance of reviving this issue with the EagerPropertyPlaceholderConfigurer? Imports based on property file settings would be a nice and familiar way to configure "sub-contexts" for different environments. I generally try to avoid global system properties in favor of containable properties files. It would be nice to consolidate the environment definition into one place, including when different context configurations are required.

A basic use case for justification purposes is that in my development environment I use SimpleTriggerBean to fire Quartz jobs immediately, but in QA and various production environments I use different CronTriggerBean configurations. I'd also imagine SpringIDE could be made to load and resolve the properties when doing imports during bean validation, which would be a nice feature as well.