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
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
This commit introduces various improvements in DataBuffer:
- DataBuffer now exposes its read and write position, as well as its
capacity and writable byte count.
- Added DataBuffer.asByteBuffer(int, int)
- DataBufferUtils.read now reads directly into a DataBuffer, rather than
copying a ByteBuffer into a DataBuffer
- TomcatHttpHandler now reads directly into a DataBuffer
Issues: SPR-16068 SPR-16070
Currently ResourceEncoder and ResourceRegionEncoder use DataBufferUtils
to read resource with an AsynchronousFileChannel if it is a file or
otherwise fallback on getting the channel from the resource.
The same is now required in other places where a Resource needs to be
read and is also generally useful.
Issue: SPR-15773
This commit changes the write methods to return `Flux<DataBuffer>`
instead of `Mono<Void>`, giving access to the original buffers,
so that they can decided whether the buffers need to be closed or not.
Issue: SPR-15726
This commit adds an overloaded write method to `DataBufferUtils`. There
are three parameter variants: `OutputStream`, `WritableByteChannel`, and
`AsynchronousFileChannel`.
Issue: SPR-15726
Arjen Poutsma
Juergen Hoeller
sdeleuze
Rossen Stoyanchev
Sam Brannen
Tony Mitchell
diesieben07