Use DataBufferUtils.compose instead of writeAggregator to combine
multiple data buffers into one, as the write aggregator would not work
when the initial data buffer did not have enough capacity to contain
all subsequent buffers.
Removed writeAggregator, as it is no longer needed.
Issue: SPR-16365
Added a utility method that composes data buffers into a single buffer.
Depending on the `DataBuffer` implementation, the returned buffer may be
a single buffer containing all data of the provided buffers, or it may
be a true composite that contains references to the buffers.
Issue: SPR-16365
As a consequence of dropping CompositeByteBuf (see prior commit),
DataBuffers fluxes that are aggregated with Flux.reduce(BiFunction) are
now required to be released, as the composite no longer holds a
reference to subsequent data buffers.
For this purpose, DataBufferUtils now has a writeAggregator that can be
used with Flux.reduce, and that released the subsequent buffers
properly.
Issue: SPR-16351
Prior to this commit, NettyDataBuffer had a optimization in
write(ByteBuf...), where it used a CompositeByteBuf to hold the original
and the parameter buffer.
Unfortunately, this procedure has nasty consequences when splicing
buffers (see https://stackoverflow.com/a/48111196/839733).
As of this commit, NettyDataBuffer stopped using CompositeByteBuf, and
simply does ByteBuf.write().
Issue: SPR-16351
This commit fixes a bug where an IllegalStateException was
thrown if the minPort and maxPort values supplied to
SocketUtils.findAvailableTcpPort(int, int) were identical.
The EXTENSION_RECEIVER parameter of Kotlin's extension
methods appear as normal method parameters to Java and
thus require a name. The synthetic name "$receiver" is
used here, as it is not a valid Kotlin identifier,
but valid in Java.
Issue: SPR-16119
This commit uses the existing CompositeByteBuf if present, as opposed
to creating a new composite for every call to
NettyDataBuffer.write(ByteBuf...)
Issue: SPR-16180
Includes fixes for invalid exception declarations in Mockito-based unit tests. Also includes FreeMarker 2.3.27, Commons Pool 2.4.3, JSON-P 1.1.2.
Issue: SPR-16157
Directly inlined hasLength implementations for proper nullability detection in IntelliJ, assuming a hasText checked value is never null afterwards. Since the JVM is going to do this at runtime anyway, this is effectively equivalent but more indicative for source code introspection algorithms.
Issue: SPR-15540
Juergen Hoeller
Arjen Poutsma
sdeleuze
Rossen Stoyanchev
Christoph Dreis
Sam Brannen
Tony Mitchell
jianglei
diesieben07