Different versions of Docker produce different responses when building
and tagging an image. On CI, a response with a stream like
"Successfully built 185991ffe24a" followed by a response with a
stream like "Successfully tagged spring-boot-it/centos:6.9-a23bced6"
is received. By default, for the building of an image to be considered
successful, the Docker Java client requires the stream for the last
response item to contain "Successfully built". This means that, on the
CI server, it incorrectly believes that the building of the tagged
image has failed.
This commit uses a custom BuildImageResultCallback that doesn't
require the last response to be the one that has a stream containing
"Successfully built". Instead, it looks back through the error-free
responses (newest to oldest) looking for one with a stream containing
"Successfully built".
CentOS 5 was declared EOL in March 2017 and yum on longer works
out of the box. 6.9 is the latest release of CentOS 6. Tests for
CentOS 7 have not been added as it uses systemd rather than SysVinit.
Closes gh-9395
Rework `org.springframework.boot.context.embedded` to relocate classes
to `org.springframework.boot.web`. Packages are now organized around
the following areas:
Packages for shared concerns, for example the `WebServer` interface
to start/stop a server and the common configuration elements:
- org.springframework.boot.web.context
- org.springframework.boot.web.server
Servlet specific packages:
- org.springframework.boot.web.servlet.server
- org.springframework.boot.web.servlet.context
- org.springframework.boot.web.servlet.filter
Reactive specific packages:
- org.springframework.boot.web.reactive.context
- org.springframework.boot.web.reactive.server
Embedded server implementations (both reactive and servlet):
- org.springframework.boot.web.embedded
In addition:
- Rename `EmbeddedServletContainerFactory` to `ServletWebServerFactory`
to align with the `ReactiveWebServerFactory`.
- Rename `EmbeddedWebApplicationContext` to
`ServletWebServerApplicationContext` and
- Rename `EmbeddedReactiveWebApplicationContext` to
`ReactiveWebServerApplicationContext`.
- Add checkstyle rules to restrict imports.
- Fixup all affected code to use the correct imports and local names.
Fixes gh-8532
The changes made for gh-8299 attempted to make static resource
handling consistent across Jetty, Tomcat, and Undertow. They did so
for application's launched using JarLauncher or WarLauncher but did
not consider application's launched in an IDE or using spring-boot:run
in Maven or bootRun in Gradle.
Running in an IDE or via Maven or Gradle introduces two new
resource locations:
- Jars on the classpath with file protocol URLs (they are always
jar protocol URLs when using either launcher)
- Directories on the classpath from a project that is depended upon
and contains resources in META-INF/resources
This commit updates the factories for all three containers to handle
these new resources locations. The integration tests have also been
updated.
Previously, there were a number of inconsistencies in the embedded
containers' handling of static resources. The Servlet spec requires
that static resources can be served from the META-INF/resources/
directory of jars nested inside a war in WEB-INF/lib/. The intention
was also to extend this to cover jar packaging when jars are nested in
BOOT-INF/lib/. This worked when using Tomcat as long as Jasper was on
the classpath. If you didn't have Jasper on the classpath or you
were using Jetty or Undertow it did not work.
This commit updates the configuration of embedded Jetty, Tomcat, and
Undertow so that all three containers handle static resources in the
same way, serving them from jars in WEB-INF/lib/ or /BOOT-INF/lib/.
Numerous intergration tests have been added to verify the behaviour,
including tests for Tomcat 8.0 and 7.0 which is supported in addition
to the default 8.5.x. Note that static resource handling only works
with Jetty 9.3.x and 9.2 and earlier does not support nested jars (
see https://github.com/eclipse/jetty.project/issues/518 for details).
Closes gh-8299
Previously, bootRepackage's excludeDevtools property would be
overridden by the springBoot extension's excludeDevtools property.
This prevented devtools from being included by configuring it on the
repackaging task.
This commit corrects the logic so that the setting on the repackaging
task takes priority. It also adds some tests to verify the behaviour.
Closes gh-8308
Emanuel Campolo
Andy Wilkinson
Spring Buildmaster
Phillip Webb