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:
- 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.
- 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: