spring-framework/org.springframework.beans
Chris Beams ebea9ec66c Introduce reserved default profile support
AbstractEnvironment and subclasses now register a reserved default
profile named literally 'default' such that with no action on the part
of the user, beans defined against the 'default' profile will be
registered - if no other profiles are explicitly activated.

For example, given the following three files a.xml, b.xml and c.xml:

    a.xml
    -----
    <beans> <!-- no 'profile' attribute -->
        <bean id="a" class="com.acme.A"/>
    </beans>

    b.xml
    -----
    <beans profile="default">
        <bean id="b" class="com.acme.B"/>
    </beans>

    c.xml
    -----
    <beans profile="custom">
        <bean id="c" class="com.acme.C"/>
    </beans>

bootstrapping all of the files in a Spring ApplicationContext as
follows will result in beans 'a' and 'b', but not 'c' being registered:

    ApplicationContext ctx = new GenericXmlApplicationContext();
    ctx.load("a.xml");
    ctx.load("b.xml");
    ctx.load("c.xml");
    ctx.refresh();
    ctx.containsBean("a"); // true
    ctx.containsBean("b"); // true
    ctx.containsBean("c"); // false

whereas activating the 'custom' profile will result in beans 'a' and
'c', but not 'b' being registered:

    ApplicationContext ctx = new GenericXmlApplicationContext();
    ctx.load("a.xml");
    ctx.load("b.xml");
    ctx.load("c.xml");
    ctx.getEnvironment().setActiveProfiles("custom");
    ctx.refresh();
    ctx.containsBean("a"); // true
    ctx.containsBean("b"); // false
    ctx.containsBean("c"); // true

that is, once the 'custom' profile is activated, beans defined against
the the reserved default profile are no longer registered. Beans not
defined against any profile ('a') are always registered regardless of
which profiles are active, and of course beans registered
against specific active profiles ('c') are registered.

The reserved default profile is, in practice, just another 'default
profile', as might be added through calling env.setDefaultProfiles() or
via the 'spring.profiles.default' property.  The only difference is that
the reserved default is added automatically by AbstractEnvironment
implementations.  As such, any call to setDefaultProfiles() or value set
for the 'spring.profiles.default' will override the reserved default
profile.  If a user wishes to add their own default profile while
keeping the reserved default profile as well, it will need to be
explicitly redeclared, e.g.:

    env.addDefaultProfiles("my-default-profile", "default")

The reserved default profile(s) are determined by the value returned
from AbstractEnvironment#getReservedDefaultProfiles().  This protected
method may be overridden by subclasses in order to customize the
set of reserved default profiles.

Issue: SPR-8203

git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4334 50f2f4bb-b051-0410-bef5-90022cba6387
2011-05-20 03:49:15 +00:00
..
.settings Merge 3.1.0 development branch into trunk 2010-10-25 19:48:20 +00:00
src Introduce reserved default profile support 2011-05-20 03:49:15 +00:00
.classpath [SPR-7850][SPR-7851] Upgraded to JUnit 4.8.1 and TestNG 5.12.1; added changelog entries for 3.1.0.M1. 2010-12-30 08:00:58 +00:00
.project adding eclipse project meta-data, .classpath file is based on dependencies listed in ivy.xml 2008-10-24 21:05:25 +00:00
beans.iml Merge 3.1.0 development branch into trunk 2010-10-25 19:48:20 +00:00
build.xml + upgrade to AspectJ 1.6.8 2010-02-04 11:46:21 +00:00
ivy.xml Merge 3.1.0 development branch into trunk 2010-10-25 19:48:20 +00:00
pom.xml Add hamcrest to beans pom in the right place to make tests compile 2010-11-16 17:12:32 +00:00
template.mf + make use or property placeholders inside template.mf 2010-02-19 09:43:22 +00:00