Closed
Description
Currently, the embedded Tomcat container does not detect and execute ServletContainerInitializers
. This means that dependencies that use them are never called and therefore are unable to contribute to the running application.
The embedded Tomcat container should be enhanced such that it properly notices the ServletContainerInitializers
on the Application's classpath and executes them.
Activity
philwebb commentedon Feb 6, 2014
This was actually an intentional design decision. The search algorithm used by the containers was problematic. It also causes problems when you want to develop an executable WAR as you often want a
javax.servlet.ServletContainerInitializer
for the WAR that is not executed when you runjava -jar
.See the
org.springframework.boot.context.embedded.ServletContextInitializer
for an option that works with Spring Beans.Do you have a specific case where this is causing problems or was it more of an observation?
nebhale commentedon Feb 7, 2014
The Cloud Foundry Java Buildpack contributes a JAR to do auto-reconfiguration (re-writing bean definitions, setting profiles, etc.). To get the auto-reconfiguration started we use a
ServletContainerInitializer
to set aServletContext
init-param
.I'm a little fuzzy on exactly how the
ServletContextInitializer
is supposed to work. Is it automatically detected in 3rd party JARs or does it have to be declared as a bean in an application'sContext
?philwebb commentedon Feb 7, 2014
The
org.springframework.boot.context.embedded.ServletContextInitializer
currently needs to be a bean. You could possibly use aApplicationContextInitializer
viaSpringFactoriesLoader
to hook in the contributions.nebhale commentedon Feb 10, 2014
I had a crack at the
SpringFactoriesLoader
this morning. I'm not claiming that I got it perfectly right, but my first impression is that it'll only work for JARs that are in the lib/ directory. Specifically, it seems that JARs passed in via-cp
aren't scanned. Is that right? Would I need to make sure that any dependency I want scanned is located in the lib directory?philwebb commentedon Feb 11, 2014
Not sure I follow. Are you saying that
SpringFactoriesLoader
doesn't pick upMETA-INF/spring.factories
files for jars passed in via-cp
?nebhale commentedon Feb 12, 2014
That's my initial indication. I've put in on the back burner for a moment while I clear out some other stuff in our backlog. Leave this issue with me for a couple of days and I'll get back to you with a definitive answer.
nebhale commentedon Mar 7, 2014
@philwebb I've finally gotten back to this particular issue and yes, I believe that
SpringFactoriesLoader
doesn't pick upMETA-INF/spring.factories
files for jars passed in via-cp
? I don't have a "simple" test-case, but I do have an example where it isn't working. I'd be happy to walk you through it or provide a (non-miminal) JAR to demonstrate.philwebb commentedon Mar 7, 2014
Unless @dsyer has time to look at this we might need to leave it as a known issue for 1.0.0. I need to focus the next few weeks on documentation and critical bugs.
Can we pick it up again when the pressure is off?
dsyer commentedon Mar 7, 2014
I don't think we'll ever be able to magically execute all SCIs. That's why I left it as "discussion". And there's definitely nothing happening to that in 1.0. We can take the
SpringFactoriesLoader
question to another issue maybe (seems like it's more of a Spring problem than a Boot problem, but maybe we are doing something in our classloaders that's messing it up).nebhale commentedon Mar 8, 2014
Yeah, no worries. I left it until much too late for you guys, and am happy to let it go. I'll open another issue with the
SpringFactoriesLoader
stuff as well.22 remaining items