Spring Framework
  1. Spring Framework
  2. SPR-7982

Support profile exclusivity and/or bean definition finality

    Details

      Description

      There's a real opportunity to nail some corner cases with profiles, and conversely the risk of propagating some open-doors to bad practice.

      Reading the example given at http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/, I can see a few areas I'd like to be explicit for fast failure:

      1. To be able to define valid (/invalid) profile combinations. In your example, you can specify "production,dev", which is clearly not what is intended, and all too easy to do when profiles are less obviously exclusive. This could be achieved by allowing profiles combinations to be specified in the application context.
      2. To be able to configure specific bean definition override behaviour, by 'final' bean defs and/or by an override flag. This could be done at the level of a bean or on the now nestable <beans> element. ** This would have saved a LOT of time on the project I've recently been working on, mainly due to the number of components developed by different teams with varying levels of Spring experience **

      I quite like the idea of allowing some combination of final and override as it would give expressiveness to developers intent. <bean id='blah' override='true' ../> would not only clearly denote that override was intended, but also allow validation that there was already a bean to override.

      Either of these suggestions would prevent the 'prod,dev' profile from being bootstrapped.

      Examples would be:

      1)

      <config>
        <profileOptions exclusive="production,dev,uat"/>
        <profileOptions exclusive="perf,trace"/>
      </config>
      

      2)

      <beans profile="production" final="true">
         ... jndi datasource bean defs
      </beans>
      <beans profile="dev" final="true">
         ... dev datasources
      </beans>
      

        Issue Links

          Activity

          Hide
          Chris Beams added a comment -

          Thanks for the submission Neale. I'm slating this for 3.2, for a few reasons:

          • It'll give that much more time for similar feedback to filter in;
          • We will also consider a move away from CGLIB during 3.2, which may open up certain opportunities like being able to use the actual final and private modifiers on @Bean methods, which we cannot currently do (SPR-5654);
          • We will revisit the idea of (re-)introducing so-called "bean definition visibility" (SPR-7170), which has some overlap with the intended goals of bean definition finality.
          Show
          Chris Beams added a comment - Thanks for the submission Neale. I'm slating this for 3.2, for a few reasons: It'll give that much more time for similar feedback to filter in; We will also consider a move away from CGLIB during 3.2, which may open up certain opportunities like being able to use the actual final and private modifiers on @Bean methods, which we cannot currently do ( SPR-5654 ); We will revisit the idea of (re-)introducing so-called "bean definition visibility" ( SPR-7170 ), which has some overlap with the intended goals of bean definition finality.
          Hide
          Dave Syer added a comment -

          I think we can and should try and offer something here in 3.1. Surely we can
          make assertions after the fact, even if we have to parse all the bean
          definitions first? It wouldn't be the most perfect solution (which has
          chicken and egg problems as you have pointed out), but just throwing an
          exception when something inconsistent is encountered would be extremely
          helpful, and probably even toolable.

          Show
          Dave Syer added a comment - I think we can and should try and offer something here in 3.1. Surely we can make assertions after the fact, even if we have to parse all the bean definitions first? It wouldn't be the most perfect solution (which has chicken and egg problems as you have pointed out), but just throwing an exception when something inconsistent is encountered would be extremely helpful, and probably even toolable.
          Hide
          Frank Scheffler added a comment -

          I think providing boolean logic on profiles would also reduce the problem a bit, i.e. defining a profile dev and also providing means to apply configuration to "not" dev environments. Effectively, dev and prod are most likely to be exlusive OR. We often happen to have the same problem with secured/unsecured and the like.

          Show
          Frank Scheffler added a comment - I think providing boolean logic on profiles would also reduce the problem a bit, i.e. defining a profile dev and also providing means to apply configuration to "not" dev environments. Effectively, dev and prod are most likely to be exlusive OR. We often happen to have the same problem with secured/unsecured and the like.
          Hide
          Chris Beams added a comment -

          Frank, I've linked this issue to SPR-9180 for reference.

          Show
          Chris Beams added a comment - Frank, I've linked this issue to SPR-9180 for reference.
          Hide
          Neale Upstone added a comment - - edited

          Watching others use profiles in anger with 3.1, I'd really like to see this polished off in 3.2.

          Rather than my original proposal here, the override approach mentioned in the highly voted SPR-5509 would solve the underlying problem, which is that beans can get overridden silently. Making overridding a bean something that has to be declared (even if just for XML - it's less of a problem with JavaConfig as we can use cleaner abstract class approaches to this), would resolve numerous issues around overridding beans.

          <bean id="bean1" ... />
          <bean override="true" id="bean1" />
          

          as the required approach to overriding beans, triggered by using the 3.2 XSD.

          This would then cause context initialisation to fail rather than silently succeed, if two incompatible profiles are activated together.

          Another thing which would be useful is if I got my finger out and did a presentation on how to split Spring projects into modules with configuration-by-contract between them (i.e. not just one single app context consuming all XML). Bad Spring XML-based library design is rather widespread in enterprise projects.

          Show
          Neale Upstone added a comment - - edited Watching others use profiles in anger with 3.1, I'd really like to see this polished off in 3.2. Rather than my original proposal here, the override approach mentioned in the highly voted SPR-5509 would solve the underlying problem, which is that beans can get overridden silently. Making overridding a bean something that has to be declared (even if just for XML - it's less of a problem with JavaConfig as we can use cleaner abstract class approaches to this), would resolve numerous issues around overridding beans. <bean id= "bean1" ... /> <bean override= "true" id= "bean1" /> as the required approach to overriding beans, triggered by using the 3.2 XSD. This would then cause context initialisation to fail rather than silently succeed, if two incompatible profiles are activated together. Another thing which would be useful is if I got my finger out and did a presentation on how to split Spring projects into modules with configuration-by-contract between them (i.e. not just one single app context consuming all XML). Bad Spring XML-based library design is rather widespread in enterprise projects.
          Hide
          Frank Scheffler added a comment -

          I am still looking forward to having this feature for selectively providing alternate configurations within XML, e.g. dummy configurations used whenever a profile is NOT active, at all.

          Show
          Frank Scheffler added a comment - I am still looking forward to having this feature for selectively providing alternate configurations within XML, e.g. dummy configurations used whenever a profile is NOT active, at all.
          Hide
          Chris Beams added a comment -

          Frank Scheffler, are you familiar with SPR-8728? It introduced a ! (not) operator for use when declaring profiles.

          Show
          Chris Beams added a comment - Frank Scheffler , are you familiar with SPR-8728 ? It introduced a ! (not) operator for use when declaring profiles.
          Hide
          Frank Scheffler added a comment -

          No, I wasn't. Thanks for the hint, I will have a look at it.

          Show
          Frank Scheffler added a comment - No, I wasn't. Thanks for the hint, I will have a look at it.

            People

            • Assignee:
              Unassigned
              Reporter:
              Neale Upstone
              Last updater:
              Chris Beams
            • Votes:
              4 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since last comment:
                1 year, 23 weeks, 6 days ago