Spring Framework
  1. Spring Framework
  2. SPR-8203

Introduce a reserved default profile name

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 3.1 M1
    • Fix Version/s: 3.1 M2
    • Component/s: None
    • Labels:
    • Last commented by a User:
      false

      Description

      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.

        Issue Links

          Activity

          Hide
          Chris Beams added a comment - - edited
          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
          
          Show
          Chris Beams added a comment - - edited 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

            People

            • Assignee:
              Chris Beams
              Reporter:
              Chris Beams
              Last updater:
              Trevor Marshall
            • Votes:
              4 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 47 weeks, 5 days ago