Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

spring-projects-issues opened this issue Sep 5, 2012 · 2 comments
in: core in: web type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Sep 5, 2012

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



  • #14398 Backport "Register environment in all bean factories in a hierarchy"
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 5, 2012

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


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 <>
Commit: Chris Beams <>

    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

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 10, 2012

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.


@spring-projects-issues spring-projects-issues added type: bug in: core in: web labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.1.3 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core in: web type: bug
None yet

No branches or pull requests

1 participant