Three Assert messages named a parameter that does not exist on the
method. In each case the correct name is already used by neighbouring
code in the same class.
Signed-off-by: kdomo <dongho5088@naver.com>
See gh-51568
There's a race between destruction of the process completing and the
test checking that the process has been destroyed. When the test
wins the race, it fails.
This commit removes the race condition by updating the test to wait
until the process has been destroyed.
Closes gh-51571
Release the output reader latch in a finally block so a failing stream
read or output consumer cannot leave ProcessRunner.run blocked on
CountDownLatch.await after the child process has exited.
Destroy the child process when waitFor is interrupted so Docker Compose
commands are not left running as orphans.
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
See gh-50963
At the time of writing, https://javaalmanac.io lists
EnumSet.spliterator as being new in Java 27, but that's not the case.
This commit switches to using String.encodedLength(Charset) instead.
This method is new in Java 27 and also aligns with the existing
TWENTY_SIX value that already uses a method on String for version
identification.
See gh-51422
This harmonizes how JSON marshaller testers operate on a stream. Also
added tests that checks the source is closed as expected for all
implementations.
Closes gh-51417
RequireNewOrMatchingContentFileHandler reads the already generated file
through content.getInputStream().readAllBytes(). That method does not
close the stream, and the stream is never assigned, so it cannot
be closed at all.
During AOT processing the content is a FileSystemResource, so each
comparison leaks a file handle. FileSystemGeneratedFiles already uses
try-with-resources when it consumes an InputStreamSource.
Read the existing content inside a try-with-resources block.
See gh-51398
Signed-off-by: dlwldn30 <dlwldn30@naver.com>
`LogbackLoggingSystem` and `Log4J2LoggingSystem` install a JUL bridge
handler only when the application is not already managing `java.util.logging`.
However, `cleanUp()` removed the bridge handler whenever the bridge class
was present on the classpath, so Spring Boot uninstalled a bridge handler
that an application had installed and managed itself.
Track whether the bridge handler was installed by Spring Boot and only
remove it during cleanup when that is the case.
See gh-50779
Signed-off-by: dhruv-15-03 <dhruvrastogi2004@gmail.com>
Manu Sridharan
Vladimir Sitnikov
kdomo
Andy Wilkinson
Sebastien Tardif
Phillip Webb
chisanw
Stéphane Nicoll
dlwldn30
dhruv-15-03
Yanming Zhou
Ahmed El amraouiyine
SJLIM