Introduce a reserved default profile name [SPR-8203]

[spring-projects-issues]

Chris Beams opened SPR-8203 and commented

Early in Spring 3.1 M1 a reserved 'default' profile name was introduced. We backed it out under the rationale that it's less magical to express defaults explicitly through spring.profiles.default or ConfigurableEnvironment#setDefaultProfiles.

This can be (re-)introduced; just wanted to keep it simple to start and see if it's truly wanted/needed.

---

Affects: 3.1 M1

Issue Links:

• Add ability to specify whether a bean profile is active by default [SPR-9281] #13919 Add ability to specify whether a bean profile is active by default ("is duplicated by")
• Support 'default' profile [SPR-7778] #12434 Support 'default' profile ("supersedes")

Referenced from: commits c4a1350

4 votes, 6 watchers

[spring-projects-issues]

Chris Beams commented

Author: Chris Beams <cbeams@vmware.com>
Date:   Fri May 20 03:49:15 2011 +0000

    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

[spring-projects-issues]

Alex Wibowo commented

Hi,

Unless I've completely missed it, I cant seem to find this behaviour documented in Spring documentation: http://docs.spring.io/spring/docs/3.2.14.RELEASE

[spring-projects-issues]

Sam Brannen commented

That's correct, Alex.

This functionality was documented after 3.2.x.

You can find the corresponding documentation in the reference manual for 4.1 and 4.2:

• http://docs.spring.io/spring/docs/4.1.0.RELEASE/spring-framework-reference/htmlsingle/#beans-definition-profiles-default
• http://docs.spring.io/spring/docs/4.2.0.RELEASE/spring-framework-reference/htmlsingle/#beans-definition-profiles-default
• http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-definition-profiles-default

[spring-projects-issues]

Alex Wibowo commented

Thanks Sam. I still think the doc for 3.2 needs to be updated, no ? Since it seems that the feature was introduced in 3.1...

[spring-projects-issues]

Sam Brannen commented

Yes, indeed: the feature was introduced in Spring 3.1; however, I don't believe that we intend to backport documentation to the 3.2.x line since it is in maintenance mode now, with 4.1 and 4.2 being actively supported and work beginning on 4.3 already.

[spring-projects-issues]

Alex Wibowo commented

Fair enough... Thanks!