Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a mechanism for adding ApplicationContextInitializers to DispatcherServlet's ApplicationContext [SPR-11314] #15938

Closed
spring-projects-issues opened this issue Jan 15, 2014 · 9 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jan 15, 2014

nebhale opened SPR-11314 and commented

Currently, there is no way to add an ApplicationContextInitializer to the DispatcherServlet's ApplicationContext at runtime (i.e. without explicit configuration on the application's part). This is possible to do on the root ApplicationContext using the contextInitializerClasses Servlet init-param.

Some mechanism (accessible from a ServletContainerInitializer) should be exposed in order to influence the DispatcherServlet's ApplicationContext and allow an ApplicationContextInitializer to be added.


Affects: 3.2.6, 4.0 GA

Reference URL: https://github.com/nebhale/spring-servlet3-autoreconfig-poc

Referenced from: commits 444b372, 5fb2665, 91881ff

Backported to: 3.2.7

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 15, 2014

Glyn Normington commented

For anyone who didn't dig into the reference URL, the goal of this feature is to support auto-reconfiguration for servlet 3 applications.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 15, 2014

Juergen Hoeller commented

I've implemented this as a "globalInitializerClasses" init-param now, basically like the existing "contextInitializerClasses" but applying to FrameworkServlets as well. They are applied right at the end of context initialization but still before locally specified "contextInitializerClasses", if any, to preserve a remaining chance for overriding.

Since this implementation is rather straightforward, I'm backporting it to 3.2.7 as well. Can't remember whether you ever asked for it, but here you go :-)

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 15, 2014

Juergen Hoeller commented

Guys, please test this over the next few days against the latest snapshots.

Would be great to have it verified to work with both 4.0.1 and 3.2.7 before that pair gets released on Jan 23...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 16, 2014

nebhale commented

Juergen Hoeller, is this a replacement for the contextInitializerClasses init-param, or in addition to it?

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 16, 2014

Juergen Hoeller commented

This is in addition to the regular contextInitializerClasses value; both settings are evaluated. However, I wouldn't expect much mixing-and-matching there.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 16, 2014

nebhale commented

Juergen Hoeller I've tried the latest snapshot (4.0.1.BUILD-20140116.115106-72) and it doesn't seem to be working. I've added the support as:

ctx.setInitParameter(ContextLoader.CONTEXT_INITIALIZER_CLASSES_PARAM,
        AutoReconfigurationApplicationContextInitializer.class.getCanonicalName());
ctx.setInitParameter(ContextLoader.GLOBAL_INITIALIZER_CLASSES_PARAM,
        AutoReconfigurationApplicationContextInitializer.class.getCanonicalName());

I still see the root context doing the right thing, but no change to the FrameworkServlet ApplicationContext.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 16, 2014

Juergen Hoeller commented

Hmm, just the "globalInitializerClasses" init-param should be sufficient for all application contexts. So there's no need to set "contextInitializerClasses" in addition. Does "globalInitializerClasses" alone apply to the root context correctly, at least?

This is how we test the FrameworkServlet effect at the moment:

public void testGlobalInitializerClasses() throws Exception {
	DispatcherServlet servlet = new DispatcherServlet();
	servlet.setContextClass(SimpleWebApplicationContext.class);
	servletConfig.getServletContext().setInitParameter(ContextLoader.GLOBAL_INITIALIZER_CLASSES_PARAM,
			TestWebContextInitializer.class.getName() + "," + OtherWebContextInitializer.class.getName());
	servlet.init(servletConfig);
	assertEquals("true", servletConfig.getServletContext().getAttribute("initialized"));
	assertEquals("true", servletConfig.getServletContext().getAttribute("otherInitialized"));
}

So I'm not sure what's not working there :-(

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 16, 2014

nebhale commented

Looks like an issue on my end (I don't think IDEA replaced my original code in the Tomcat container), but it appears to work. This should be exactly what we need. Thanks for the work.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 16, 2014

Juergen Hoeller commented

Cool, good to hear :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants