Provides a convenient mechanism for activating an additional profile
while preserving those that are already active, as opposed to
calling #setActiveProfiles with the contents of #getActiveProfiles plus
the new profile.
Issue: SPR-8548
For consistency with all other constants representing default
property source names, such as
StandardServletEnvironment#SERVLET_CONTEXT_PROPERTY_SOURCE_NAME and
StandardEnvironment#SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME
Issue: SPR-8482
Users may now work with command line arguments as a source of
properties for use with the PropertySource and Environment APIs.
An implementation based on the jopt library and a "simple"
implementation requiring no external libraries are are provided
out-of-the box.
See Javadoc for CommandLinePropertySource, JOptCommandLinePropertySource
and SimpleCommandLinePropertySource for details.
Issue: SPR-8482
Prior to this change, the Property class introduced in 3.1 M2 validated
read/write property method pairs based on whether their parameter/return
types were equal to one another. This precluded the valid possibility
of read method that returns a subtype of the write method's parameter
type, and represented a regression against 3.1 M1 and earlier versions.
The implementation now uses isAssignableFrom rather than a straight
equals check against the types.
Issue: SPR-8432
Attempt to access and modify the system environment works on OS X /
Linux but not under Windows. Does not represent any real failure for
production code - the need to modify the system environment is a
testing concern only, and one we can probably live without, considering
the losing battle necessary to make such a hack cross-platform.
Issue: SPR-8245
ClassMetadata implementations can now introspect their member (nested)
classes. This will allow for automatic detection of nested
@Configuration types in SPR-8186.
Issue: SPR-8358,SPR-8186
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
Allows convenient creation of a Properties-based PropertySource from a
Spring Resource object or resource location string such as
"classpath:com/myco/app.properties" or "file:/path/to/file.properties"
Issue: SPR-8328
