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>
AppendableByteArray.reset() was only called from toByteArray(), so an
encode that failed part-way left its partial output in the thread-local
cached instance. The next value encoded on that thread was then prefixed
with it, which in structured logging corrupted the log event following a
failed one.
Reset the cached instance when it is handed out instead, so the buffer
is clean regardless of how the previous use ended. This also covers the
early return in toByteArray() for empty content, which returns without
resetting.
See gh-51156
Signed-off-by: Sumit Kumar Das <skdas5405@gmail.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>
Andy Wilkinson
Sebastien Tardif
Phillip Webb
Manu Sridharan
chisanw
Stéphane Nicoll
dlwldn30
Sumit Kumar Das
dhruv-15-03
Yanming Zhou
Ahmed El amraouiyine
SJLIM