Prior to this commit, the exception message generated by
instantiateFactory() in SpringFactoriesLoader did not report the
offending class in the top-level exception message. The offending class
was in fact included in the message of the nested exception, but the
top-level exception message on its own was a bit misleading.
This commit improves the diagnostics for such failures by including the
offending class and the target factory type in the top-level exception
message.
Closes gh-22453
Before this commit, the return type for Kotlin suspending functions
(as returned by MethodParameter#getParameterType and
MethodParameter#getGenericReturnType methods) was incorrect.
This change leverages Kotlin reflection instead of Java one
to return the correct type.
Closes gh-21058
- Integration tests run with zero copy configuration.
- RSocketBufferLeakTests has been added.
- Updates in MessagingRSocket to ensure proper release
See gh-21987
Prior to this commit, repeated calls to `DataBuffer.write(CharSequence,
Charset)` would not write the given chars to the expected position in
the original buffer.
This commit fixes that by writing to the `outBuffer.position()`, offset
by the current `DataBuffer.writePosition()`.
Fixes gh-22484
Prior to this commit, `DataBuffer.write` would throw an
`IllegalStateException` when called with an empty `String`, since the
`CharsetEncoder` would be flushed on an incorrent state.
This commit skips entirely the encoding phase for empty `String`.
Fixes#22262
Prior to this commit, one could write a `CharSequence` to an existing
`DataBuffer` instance by turning it into a byte array or `ByteBuffer`
first. This had the following disadvantages:
1. Memory allocation was not efficient (not leveraging pooled memory
when available)
2. Dealing with `CharsetEncoder` is not always easy
3. `DataBuffer` implementations, like `NettyDataBuffer` can use
optimized implementations in some cases
This commit adds a new `DataBuffer#write(CharSequence, Charset)` method
for those cases and also an `ensureCapacity` method useful for checking
that the current buffer has enough capacity to write to it..
Issue: SPR-17558
This commit reverts the first optimizations listed in
fa096dc60f, as the default delimiters
do vary, namely by the charset given in the message mime type.
The mimetype charset might not be compatible with ASCII (i.e. anything
but UTF-8 or ISO-8859-1, for instance it might be UTF-16), and will not
successfully find the default delimiters as a consequence.
Added test to indicate the bug.
Fix ResourceRegionEncoder so that it checks for resource existance
before writing boundaries. Also defer data buffer allocation until
necessary.
Issue: SPR-17419
As discussed in KT-25165, from a Kotlin POV enum constructors
have no parameter, this is an "implementation detail"
required for running on the JVM, so it seems relevant to skip
Kotlin reflection in that case and just delegate to Java
reflection.
Issue: SPR-16931
Includes use of Files.getLastModifiedTime for NIO Paths, preservation of NIO-based resolution on createRelative, deprecation of PathResource, and consistent use of getContentLengthLong over getContentLength.
Issue: SPR-17320
This was a package private class in spring-messaging since 5.0, and was
recently made public in 5.1. This commit promotes it to spring-core
where it belongs next to all other ListenableFuture support classes.
Follow-up refactoring for SPR-17336
