Calls to AbstractApplicationContext#setParent delegate the parent
context environment to the child.
This ensures that any property sources added to the parent are available
to the child as well as ensuring that any profiles activated are
activated everywhere.
Child contexts may still choose to replace their environment (through an
ApplicationContextInitializer, for example). In any case, however, in
the root/child web application context relationship established by
ContextLoader + DispatcherServlet, the child is guaranteed to have
already been given the parent environment by the time it is delegated
to any ACIs.
See AbstractApplicationContext#setParent for implementation
See FrameworkServlet#createWebApplicationContext for order in which
setParent then initializeWebApplicationContext are called.
Issue: SPR-8185
AnnotationConfigApplicationContext and
AnnotationConfigWebApplicationContext both expose #register and #scan
methods as of the completion of SPR-8320. This change introduces a new
interface that declares each of these methods and refactors ACAC and
ACWAC to implement it.
Beyond information value, this is useful for implementors of the
ApplicationContextInitializer interface, in that users may create an ACI
that works consistently across ACAC and ACWAC for standalone (e.g.
testing, batch) or web (e.g. production) use.
Issue: SPR-8365,SPR-8320
Primarily for use in conjunction with ApplicationContextInitializer,
these new #scan and #register methods mirror those in
AnnotationConfigApplicationContext. #setConfigLocation
and #setConfigLocations methods remain for compatibility with
ContextLoader-style initialization, but have been locally overridden
and documented clearly.
AnnotationConfigWebApplicationContext#loadBeanDefinitions Javadoc has
also been updated to explain the processing logic for each of these
potential inputs.
Issue: SPR-8320
FrameworkServlet now has support equivalent to ContextLoader and its
"contextInitializerClasses" context-param introduced in 3.1 M1.
This allows users to specify ApplicationContextInitializers at the root
(ContextLoader) level and/or at the DispatcherServlet level.
Issue: SPR-8366
The following is now possible:
@Configuration
public class AppConfig {
@Inject DataSource dataSource;
@Bean
public MyBean myBean() {
return new MyBean(dataSource);
}
@Configuration
static class DatabaseConfig {
@Bean
DataSource dataSource() {
return new EmbeddedDatabaseBuilder().build();
}
}
}
public static void main(String... args) {
AnnotationConfigApplicationContext ctx =
new AnnotationConfigApplicationContext(AppConfig.class);
ctx.getBean(MyBean.class); // works
ctx.getBean(DataSource.class); // works
}
Notice that the @Import annotation was not used and that only AppConfig
was registered against the context. By virtue of the fact that
DatabaseConfig is a member class of AppConfig, it is automatically
registered when AppConfig is registered. This avoids an awkward and
redundant @Import annotation when the relationship is already implicitly
clear.
See @Configuration Javadoc for details.
Issue: SPR-8186
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
This new hook in the AbstractEnvironment lifecycle allows for more
explicit and predictable customization of property sources by
subclasses. See Javadoc and existing implementations for detail.
Issue: SPR-8354
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
- removed generics from Cache/CacheManager (they add no value since it's an SPI not API)
+ update docs and tests
+ renamed ConcurrentCacheFactoryBean to ConcurrentMapCacheFactoryBean
Revert signature of
ConfigurationClassPostProcessor#processConfigBeanDefinitions to its form
found in the 3.0.x line. Refactorings made during 3.1 development
caused otherwise package-private types such as
ConfigurationClassBeanDefinitionReader to escape through this public
method, causing issues for STS as well as being a general design issue.
Upon review, the refactorings could easily be backed out in favor of a
simpler approach, and this has been done.
This also means that ConfigurationClassBeanDefinitionReader can return
to package-private visibility, and this change has been made as well.
Issue: SPR-8200
Rossen Stoyanchev
Keith Donald
Sam Brannen
Chris Beams
Arjen Poutsma
Costin Leau
Oliver Gierke