For background, see http://blog.springsource.org/2011/02/14/spring-3-1-m1-introducing-profile/#comment-223530 and http://www.linuxquestions.org/questions/linux-general-1/is-it-possible-to-set-an-environment-variable-name-containing-a-period-in-bash-724256/.
The following is not possible in bash:
As bash does not support '.' in variable names:
This means that it is currently not possible to set active or default profiles via the system environment if one is using bash. Nor is it possible to use the system environment for resolution of any other user-defined property using the PropertySource/Environment API developed as part of Spring 3.1.
Note that this is possible under other shells, such as tcsh:
There are several possible solutions, the simplest of which would be to change the property name from spring.profiles.active to spring_profiles_active or something similar that bash does not take issue with. However, this is undesirable, because it suggests that all properties to be resolved through the PropertySource mechanism should avoid '.' characters. This goes strongly against convention in java, where such naming is common (think about .properties files here. This 'solution' would also have the negative effect of breaking all existing applications running against 3.1 milestones and release candidates at this point, as well as all documentation and blog post that have been written about profile support and it's activation mechanisms.
Therefore, the better solution is probably to provide custom support at the environment property source level, allowing for interchangeability of '.' and '_' characters. This would allow for the following:
as well as the following
This would apply generally, such that a call to resolve property foo.bar, e.g.:
would return non-null assuming that the Environment object env contains a system environment PropertySource and there is an environment variable present named foo.bar or foo_bar.
In the rare case that both variables foo.bar and foo_bar are present in the environment (possible under tcsh, for example), then the variable matching the original request will be the one returned. That is, a call to getProperty("foo.bar") will return the value of foo.bar, and a call to getProperty("foo_bar") will return the value of foo_bar.
Appropriate debug logging will be added to inform the user when this is occurring.
It may also make sense to allow for case-insensitivity when resolving properties against the system environment PropertySource, which will allow for more idiomatic invocation, e.g.:
Javadoc will be updated to reflect these changes at the appropriate locations.