Support profile exclusivity and/or bean definition finality [SPR-7982]

[spring-projects-issues]

Neale Upstone opened SPR-7982 and commented

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:

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

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

---

Affects: 3.1 M1

Reference URL: http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/#comment-185086

Issue Links:

• Revised support for bean definition visibility and overriding [SPR-8189] #12839 Revised support for bean definition visibility and overriding ("is depended on by")
• @Bean(override=true) [SPR-8528] #13172 @Bean(override=true) ("is duplicated by")
• Allow @Bean methods to override definitions in XML [SPR-7028] #11690 Allow @Bean methods to override definitions in XML
• Provide boolean logic on bean profiles, i.e. NOT profile. [SPR-9180] #13818 Provide boolean logic on bean profiles, i.e. NOT profile.
• Support not (!) operator for profile selection [SPR-8728] #13370 Support not (!) operator for profile selection
• Bean Configuration Overriding [SPR-5509] #10181 Bean Configuration Overriding
• Support @Bean method visibility [SPR-7170] #11829 Support @Bean method visibility

6 votes, 12 watchers

[spring-projects-issues]

Chris Beams commented

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 (Consider using javassist for proxy generation [SPR-5654] #10325);
• We will revisit the idea of (re-)introducing so-called "bean definition visibility" (Support @Bean method visibility [SPR-7170] #11829), which has some overlap with the intended goals of bean definition finality.

[spring-projects-issues]

Dave Syer commented

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.

[spring-projects-issues]

Frank Scheffler commented

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.

[spring-projects-issues]

Chris Beams commented

Frank, I've linked this issue to #13818 for reference.

[spring-projects-issues]

Neale Upstone commented

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 #10181 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.

[spring-projects-issues]

Frank Scheffler commented

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.

[spring-projects-issues]

Chris Beams commented

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

[spring-projects-issues]

Frank Scheffler commented

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

[spring-projects-issues]

Juergen Hoeller commented

This has largely been superseded by the generalized condition model in 4.0 (and by various refinements to the profile mechanism in 3.2 ahead of that). If there is anything to be desired still, please raise a focused issue against 4.3 / 5.0.