There is no longer a reserved default profile named 'default'. Rather,
users must explicitly specify a default profile or profiles via
ConfigurableEnvironment.setDefaultProfiles(String...)
- or -
spring.profile.default="pD1,pD2"
Per above, the setDefaultProfile(String) method now accepts a variable
number of profile names (one or more). This is symmetrical with the
existing setActiveProfiles(String...) method.
A typical scenario might involve setting both a default profile as a
servlet context property in web.xml and then setting an active profile
when deploying to production.
Before this change, the following properties could be used to manipulate
Spring profile behavior:
-DspringProfiles=p1,p2
-DdefaultSpringProfile=pD
These properties have been renamed to follow usual Java conventions for
property naming:
-Dspring.profile.active=p1,p2
-Dspring.profile.default=pD
'default' is now a reserved profile name, indicating
that any beans defined within that profile will be registered
unless another profile or profiles have been activated.
Examples below are expressed in XML, but apply equally when
using the @Profile annotation.
EXAMPLE 1:
<beans>
<beans profile="default">
<bean id="foo" class="com.acme.EmbeddedFooImpl"/>
</beans>
<beans profile="production">
<bean id="foo" class="com.acme.ProdFooImpl"/>
</beans>
</beans>
In the case above, the EmbeddedFooImpl 'foo' bean will be
registered if:
a) no profile is active
b) the 'default' profile has explicitly been made active
The ProdFooImpl 'foo' bean will be registered if the 'production'
profile is active.
EXAMPLE 2:
<beans profile="default,xyz">
<bean id="foo" class="java.lang.String"/>
</beans>
Bean 'foo' will be registered if any of the following are true:
a) no profile is active
b) 'xyz' profile is active
c) 'default' profile has explicitly been made active
d) both (b) and (c) are true
Note that the default profile is not to be confused with specifying no
profile at all. When the default profile is specified, beans are
registered only if no other profiles are active; whereas when no profile
is specified, bean definitions are always registered regardless of which
profiles are active.
The default profile may be configured programmatically:
environmnent.setDefaultProfile("embedded");
or declaratively through any registered PropertySource, e.g. system properties:
-DdefaultSpringProfile=embedded
Assuming either of the above, example 1 could be rewritten as follows:
<beans>
<beans profile="embedded">
<bean id="foo" class="com.acme.EmbeddedFooImpl"/>
</beans>
<beans profile="production">
<bean id="foo" class="com.acme.ProdFooImpl"/>
</beans>
</beans>
It is unlikely that use of the default profile will make sense in
conjunction with a statically specified 'springProfiles' property.
For example, if 'springProfiles' is specified as a web.xml context
param, that profile will always be active for that application,
negating the possibility of default profile bean definitions ever
being registered.
The default profile is most useful for ensuring that a valid set of
bean definitions will always be registered without forcing users
to explictly specify active profiles. In the embedded vs. production
examples above, it is assumed that the application JVM will be started
with -DspringProfiles=production when the application is in fact in
a production environment. Otherwise, the embedded/default profile bean
definitions will always be registered.
Branch in question is 'env' branch from git://git.springsource.org/sandbox/cbeams.git; merged into
git-svn repository with:
git merge -s recursive -Xtheirs --no-commit env
No merge conflicts, but did need to
git rm spring-build
prior to committing.
With this change, Spring 3.1.0 development is now happening on SVN
trunk. Further commits to the 3.0.x line will happen in an as-yet
uncreated SVN branch. 3.1.0 snapshots will be available
per the usual nightly CI build from trunk.
Before:
- new GenericXmlApplicationContext("com/acme/path/to/resource.xml");
- GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("com/acme/path/to/resource.xml");
ctx.refresh();
After:
- The above remain supported, as well as new class-relative variants
- import com.acme.path.to.Foo;
new GenericXmlApplicationContext(Foo.class, "resource.xml");
- import com.acme.path.to.Foo;
GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load(Foo.class, "resource.xml");
ctx.refresh();
These changes are generally aligned with signatures long available in
ClassPathXmlApplicationContext. As GenericXmlApplicationContext is
intended to be a more flexible successor to CPXAC (and FSXAC), it's
important that all the same conveniences are available.
GenericApplicationContext and AbstractRefreshableApplicationContext
implementations now call DefaultListableBeanFactory.setSerializationId()
only upon successful refresh() instead of on instantiation of the
context, as was previously the case with GAC.
DLBF.setSerializationId() adds the beanFactory to the *static*
DLBF.serializableFactories map, and while calling close() on the
application context removes entries from that map, it does so only if
the context is currently active (i.e. refresh() has been called).
Also, cancelRefresh() has been overridden in GAC just as it has been
in ARAC to accomodate the possibility of a BeansException being thrown.
In this case, the beanFactory serializationId will be nulled out and
the beanFactory removed from the serializableFactories map.
The SerializableBeanFactoryMemoryLeakTests test case provides full
coverage of these scenarios.
Hibernate validator had been updated to 4.1.0 in the ivy metadata, but
not yet reflected in the .classpath file. The pom.xml had been updated
but there was a typo - scope read 'coompile', instead of 'compile'.
Chris Beams
Juergen Hoeller
Ramnivas Laddad
Ben Hale
Arjen Poutsma
David Syer