Register environment in all bean factories in a hierarchy [SPR-9756]

[spring-projects-issues]

Patrick Schultz opened SPR-9756 and commented

Attached maven project to demonstrate bug.

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).

---

Affects: 3.1.2

Attachments:

• propertysource-web-bug.zip (13.95 kB)

Sub-tasks:

• Backport "Register environment in all bean factories in a hierarchy" [SPR-9764] #14398 Backport "Register environment in all bean factories in a hierarchy"

[spring-projects-issues]

Chris Beams commented

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).

See https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-9756
and https://github.com/SpringSource/spring-framework-issues#readme

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.

commit f963d0f190b60d56653a1dd4fd5119fb3ba70969
Author: Chris Beams <cbeams@vmware.com>
Commit: Chris Beams <cbeams@vmware.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

[spring-projects-issues]

Juergen Hoeller commented

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.

Juergen