Previously the server was started to make the ServletContext
available, then, to prevent requests from being handled before the
application context had been started, the connectors were stopped.
Once application context startup had completed, the connectors were
then started again. In addition to being somewhat inefficient, this
caused problems on FreeBSD where stopping the connector didn't free
up the port quickly enough for the subsequent start to then be able
to bind to it.
This commit updates the Jetty startup logic to be closer to the logic
that's used for Tomcat. Before the server is started, the configured
connectors are cached and then removed. The server is then started
without any connectors. Once application context startup has
completed, the connectors are reinstated and started.
Fixes#968
Often this change will not be important because you are binding to
a bean with strongly typed properties. A bean with a Map property,
on the other hand, won't oytherwise be able to reason about the
permitted keys so it will miss any non-enumerable property sources,
including composites whose nested sources are themselves enumerable.
Fixed gh-1294
Before this change a property whose key was in a non-enumerable property source would
not resolve placeholders, leading to ${style} values in @ConfigurationProperties beans
even if the placeholders ere resolvable.
Both embedded containers need to be checked after starting to ensure that they
are actually running. With Jetty it's just a question of catching an exception
but with Tomcat it's harder (the current solution involves duplicating some
code from initialize() into start() essentially checking the lifecycle state).
Also adjusted the log levels to prevent noise at WARN level by default when
this happens (since the exception is logged and rethrown anyway).
There is still the issue of whether to fail the build in Maven or Gradle
(separate issue really).
Fixes gh-1232
Update TomcatEmbeddedServletContainer so that Connectors are removed
during initialization and re-added when the start() method is called.
This prevent protocol handlers from being bound then immediately
unbound. It also ensure that any additional connectors that may have
been added don't accidentally start to accept traffic (which could cause
potential deadlock issues).
Fixes gh-1212
Previously, SpringApplication would set the java.awt.headless system
property even if it had already been set. This commit updates
SpringApplication to honour any existing configuration when setting
the property.
Fixes#1189
* The SpringApplicationBuilder was registering the parent context initializer
twice (not really a problem, but confusing if you are debugging).
* ParentContextApplicationContextInitializer itself should have been
checking that the current context is not the parent
* The EventPublishingRunListener as a result needs to call
setApplicationContext on any listeners that are AplicationContextAware
* ParentContextCloserApplicationListener can ensure that there is
only one of its kind per application context by implementing hashCode
and equals
Fixes gh-1142
Tomcat 8 has different APIs again so it was quite difficult to
get it working and test it. The test is manual anyway (multi-module
project with JSPs in /META-INF/resources, not part of the samples),
and requires you to build a war and execute it (since the resource
paths are different when it's an archive).
Fixes gh-1131
This commit reuses the standard behavior provided by Properties for
parsing keys rather than parsing the keys ourselves. This provides a
consistent features set regardless of where the property is defined.
Fixes gh-1110
Prior to this commit, some tests were creating a parent/child
relationship but were only closing the child context. This could
be an issue with the autoconfig module as a lot of auto-config
kicks in by default.
This commit adds a new test utility designed to properly handle
those situations. Updated tests that were creating a context
hierarchy to benefit from that.
Fixes gh-1034
To ensure an MBeanServer is available when needed you have to
look in JNDI before resorting to the JDK platform factory.
I had to copy some private code from Spring, but it seems
worth it.
Fixes gh-1092
