Properties files that are scanned are not used in the resolution of key lookup later in the application lifecycle. The property file is missing from the list of available property sources.
Bug is limited to 3.1.2 (code functions as expected in 3.1.1) and to those projects that use the ContextLoaderListener (removing it from the web.xml causes the value to be found in the properties file).
I have yet to find the exact root cause or a workaround (removing the ContextLoaderListener is not an option).
Thanks, Patrick for the report and repro project. Note that I've uploaded a simplified version of the project to the spring-framework-issues project (which you might care to read up on next time around).
This is now fixed and will be shortly available in 3.2.0.BUILD-SNAPSHOT, and keep an eye on #14398 for status on the backport into 3.1.3.
Author: Chris Beams <firstname.lastname@example.org>
Commit: Chris Beams <email@example.com>
Register environment in all bean factories in a hierarchy
Prior to this change, AbstractApplicationContext#prepareBeanFactory
registered a bean named 'environment' once and only once within a given
ApplicationContext hierarchy. This worked fine with the expectation
that the Environment object is always delegated downward to children of
that hierarchy. However, with SPR-9444 and the introduction of
ConfigurableEnvironment#merge, this expectation was violated; each
member of an application context hierarchy now maintains its own
distinct Environment instance, which means that by extension that each
application context's underlying BeanFactory should have its own
'environment' bean pointing to that context's environment instance.
This problem could manifest in getting the wrong environment instance
when calling #getBean(Environment) or when @Autowiring an Environment
instance, for example into a @Configuration class. As reported in
SPR-9756, this could result in false negative property lookups or
incorrect results when checking whether a profile is active.
This commit ensures that every bean factory in an application
hierarchy has an 'environment' bean referring to the object returned
from the enclosing ApplicationContext#getEnvironment method.
Issue: SPR-9756, SPR-9444
Along with the 3.1.3 backport, I've refined this to set the "systemProperties" and "systemEnvironment" beans at each factory level as well. Technically, those could be different depending on the local Environment, just like the "environment" bean itself.