Constructors have been added to both ContextLoader and
ContextLoaderListener to support instance-based programmatic
registration of listeners within ServletContainerInitializer
implementations in Servlet 3.0+ environments, and more particularly
when using Spring 3.1's WebApplicationInitializer SPI.
Issue: SPR-7672
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4382 50f2f4bb-b051-0410-bef5-90022cba6387
ContextLoader and FrameworkServlet now use
AnnotationAwareOrderComparator to support @Order usage; previously
supported only implementation of the Ordered interface.
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4381 50f2f4bb-b051-0410-bef5-90022cba6387
Constructors have been added to both FrameworkServlet and
DispatcherServlet to support instance-based programmatic registration
of Servlets within ServletContainerInitializer implementations in
Servlet 3.0+ environments, and more particularly when using Spring 3.1's
WebApplicationInitializer SPI.
This change also renames the method added to FrameworkServlet in
SPR-8185 from #initializeWebApplicationContext to #applyInitializers.
The reason being that a method named #initWebApplicationContext was
already present and the names overlapped confusingly.
Issue: SPR-7672, SPR-8185
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4380 50f2f4bb-b051-0410-bef5-90022cba6387
GenericWebApplicationContext now implements
ConfigurableWebApplicationContext in order to be compatible with
Framework/DispatcherServlet and ContextLoader/Listener, especially with
regard to changes in SPR-7672 that allow for programmatic use of these
types within Servlet 3.0+ environments. For the first time, it's now
reasonable to imagine injecting a GWAC into DispatcherServlet; the most
robust way to accommodate this possibility is for GWAC to implement
CWAC.
The implementation is in name only, allowing for interchangable use of
GWAC anywhere, for example, an XWAC could otherwise go. Methods such
as setConfigLocation will throw UnsupportedOperationException if the
configLocation value actually contains text. Other methods are
implemented as no-ops or to throw UOE as appropriate.
Issue: SPR-7672
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4378 50f2f4bb-b051-0410-bef5-90022cba6387
WebApplicationInitializer provides a programmatic alternative to the
traditional WEB-INF/web.xml servlet container deployment descriptor
for Servlet API 3.0+ environments.
This is done by building atop the new ServletContainerInitializer
support in Servlet 3.0. See SpringServletContainerInitializer for
complete details. And see WebApplicationInitializer Javadoc for
typical usage examples.
Issue: SPR-7672
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4377 50f2f4bb-b051-0410-bef5-90022cba6387
In support of SPR-7672 which will support code-based configuration
alternatives to web.xml using new features in the Servlet 3.0 API.
This upgrade does *not* force Spring users to upgrade to Servlet 3.0
capable containers. Compatibility with and support for
javax.servlet >= 2.4 remains.
Issue: SPR-7672
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4365 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4353 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4352 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4351 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4350 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4343 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4335 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4334 50f2f4bb-b051-0410-bef5-90022cba6387
Chris Beams
Juergen Hoeller
Rossen Stoyanchev
Arjen Poutsma
Keith Donald
Sam Brannen