Declarative registration for ApplicationContextInitializer [SPR-8274]

[spring-projects-issues]

Scott Andrews opened SPR-8274 and commented

We need to be able to augment the application environment when our library is deployed in an application. Currently, we use an ApplicationContextInitializer that must be registered in web.xml for every application that wishes to utilize. We would like to remove the need to register the initializer in web.xml.

An ApplicationContextInitializer should be automatically discoverable without requiring manual user registration.

I propose we use classpath*:META-INF/spring.bootstrap to register via the class path. Inside this file:

initializer=com.example.MyApplicationContextInitializer

This file can also be used for other bootstrapping concerns in the future.

---

Affects: 3.1 M1

Issue Links:

• Support configuring Servlet container in Spring using Servlet 3.0 programmatic config [SPR-7672] #12328 Support configuring Servlet container in Spring using Servlet 3.0 programmatic config ("is superseded by")

[spring-projects-issues]

Chris Beams commented

ApplicationContextInitializer implementations declared in spring.bootstrap will be applied to every ApplicationContext created by the deployment unit.

This means that in a web application, both the DispatcherServlet context and root context will be initialized. Assuming that the ACI(s) in question do nothing more than enable / disable profiles and contribute to the Environment's set of PropertySources, this is probably a desirable outcome. @Scott, can you please confirm that this is your intention, and that this caveat is compatible with your use case?

We will strongly recommend against registering bean definitions against the context in these ACI implementations, because the author of a given library that includes spring.bootstrap simply cannot predict when and where the user will create ApplicationContext objects, and automatically registering bean definitions (especially 'active' bean definitions that participate in the container lifecycle) may be a most unwelcome surprise to the user.

[spring-projects-issues]

Scott Andrews commented

Correct. For Cloud Foundry, we are only looking to provide a property source and enable profiles. We will not be creating bean definitions, or otherwise modifying the beans graph.

[spring-projects-issues]

Chris Beams commented

After plenty of investigation and discussions with Scott, we're marking this as WON'T FIX for now, for several reasons:

1. CloudFoundry already has a web.xml rewriting mechanism that can introduce an ACI, so it's not strictly necessary anyway
2. Bootstrapping ACIs automatically just has too many negative side effects.
3. Spring 3.1's recent support for Servlet 3.0 ServletContainerInitializer through the new WebApplicationInitializer SPI provide similar capabilities in a more predictable and robust fashion.

To point (3) above, WAI instances are applied on a per-servlet container basis, not on a per-application context basis -- this is the right granularity and avoids the side effects mentioned in (2) above. If desired, CF could package their own WebApplicationInitializer and it would automatically be applied. CF should also look into the possibility of contributing web-fragment.xml snippets in Servlet 3.0-capable environments. This is probably the most standards-friendly and unsurprising thing to do. WebApplicationInitalizers are generally intended to be for user consumption, not framework consumption (though this isn't a strict rule).