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
Previously, BeanCurrentlyInCreationFailureAnalyzer would return
a FailureAnalysis for any BeanCurrentlyInCreationException even if
it could not determine where the cycle begins. This could lead to an
inaccurate diagram of the cycle being output.
This commit updates BeanCurrentlyInCreationFailureAnalyzer so that
it abandons its analysis and returns null if it is unable to determine
where the cycle begins.
Closes gh-8164
Calling launch of PropertiesLauncherTests sets the thread context
class loader to an instance of LaunchedURLClassLoader. To avoid this
class loader being used beyond the scope of the test and launcher
that created it, this commit updates PropertiesLauncherTests to
capture the TCCL before each test and restore it after each test.
Closes gh-9378
Previously, if Jetty's thread pool was misconfigured, the Server would
still start successfully.
When it is started, the Server examines its Connectors to determine
how many threads are required. If its thread pool does not meet the
Connectors' requirements, an IllegalStateException is thrown and the
Server fails to start. However, JettyEmbeddedServletContainer
temporarily removes the Server's Connectors while it is being started
so that requests will not be accepted until the application is ready.
This has the unwanted side-effect of causing a misconfigured thread
pool to go undetected as the Connectors' thread requirements are not
taken into consideration.
The verification of the thread pool configuration and the starting of
the Connectors is done in the Server's doStart() method which has
three steps that are of interest:
1. Verify the Server's thread pool configuration
2. Start any managed beans that have been added to the Server
3. Start the Server's Connectors.
To allow the thread pool configuration to be verified while still
preventing the Connectors from being started, the Connectors need to
be removed in step 2. This is achieved by registering a managed bean
with the Server that nulls out the Server's Connectors as part of its
doStart() method.
Closes gh-8917
This commit makes sure to apply Atomikos defaults also adds a test that
validates Atomikos defaults are consistent.
As a side effect of that, `threadedTwoPhaseCommit` is now `false` (which
is effectively what users got with no customization anyway since that
default was changed in Atomikos 3.7
Closes gh-9141
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Oleg Vyukov
Wesley Stratton
hengyunabc