Put the lambda parameter at the end and use a function
instead of a supplier to be able to register beans like this:
val context = GenericApplicationContext()
context.registerBean(Foo::class)
context.registerBean{ Bar(it.getBean(Foo::class)) }
Issue: SPR-15118
Based on an idea from Mario Arias, we can avoid requiring specifying
explicitly Supplier lambda type in Kotlin API by declaring the supplier
parameter as "crossinline supplier: () -> T" instead of
"supplier: Supplier<T>".
Issue: SPR-15118
After the upgrade to JUnit Jupiter 5.0 M3, JUnit Jupiter tests in the
Spring build were no longer executed due to the introduction of a
default test class name pattern.
This commit addresses this issue by making use of the
@IncludeClassNamePatterns to specify that *TestCase test classes should
be executed within the org.springframework.test.context.junit.jupiter
package.
Prior to this commit, the `ResourceHttpMessageConverter` would support
converting from an `HttpInputMessage` to a `InputStreamResource`. This
is valid when reading resources on the server side, but it's not
compatible with the way `RestTemplate` works.
The API exposed by `RestOperations` imply that the HTTP server response
should be fully consumed and properly closed by the time the `exchange`
method returns. In other words, this HTTP client does not support
streaming the HTTP response.
This commit allows the `ResourceHttpMessageConverter` to be configured
to disable read streaming when used in `RestTemplate`.
Issue: SPR-14882
Codacy warns us that there are several references to Boolean
constructors in the tests. Direct usage of the Boolean constructor is
discouraged and even deprecated in Java 9 [1]. Boolean constructor use
can easily be replaced with the constant instances.
This commit contains the following changes:
- replace references to Boolean constructors with boolean constants in
JSP tag tests
- update the copyright year where necessary
- BooleanComparatorTests is intentionally left unchanged as it should
also work with the non-constant instances correctly
[1] http://download.java.net/java/jdk9/docs/api/java/lang/Boolean.html#Boolean-boolean-
Issue: SPR-15076
Codacy warns about an Error Prone [1] use of the double constructor of
BigDecimal in tests. The reason given is that it is a source of
precision loss if the number does not have an exact double
representation. The recommendation is to use the String constructor of
BigDecimal instead as it does not require using a lossy argument.
This commit contains the following changes:
- replace usage of the double constructor of BigDecimal with the
String constructor of BigDecimal in JdbcTemplateQueryTests
- update the copyright year
[1] http://errorprone.info/bugpattern/BigDecimalLiteralDouble
Issue: SPR-15077
ScriptUtils contains two calls to String#toCharArray for the sole
purpose to iterating over all chars in a String. Not only is this
unnecessary and can be replaced with String#charAt it also causes
additional allocator and heap pressure because String#toCharArray
rather than returning the backing array (which is gone in Java 9)
creates a copy.
This commit contains the following changes:
- remove String#toCharArray from ScriptUtils and replace with
String#charAt
Issue: SPR-15075
Prior to this commit, the `ResourceRegionHttpMessageConverter` would
rely on the default implementation of `getDefaultContentType` to guess
the default Content-Type of the resource region to be written to the
HTTP response. That implementation fetches the first media type
provided in the HTTP request "Accept" header.
This behavior is not correct when converting resources and this commits
aligns this converter with the `ResourceHttpMessageConverter` which uses
JAF to guess the correct Content-Type of the given resource, or just
returns "application/octet-stream" as a default value.
Issue: SPR-15041
Kotlin JSR 223 support currently requires kotlin-script-util
dependency (jcabi-aether, maven-core and aether-api can be
excluded since they are only used for live import of
dependencies and bring a lot of JARs in the classpath) and a
/META-INF/services/javax.script.ScriptEngineFactory
file specifying the ScriptEngineFactory to use, in that case
org.jetbrains.kotlin.script.jsr223.KotlinJsr223JvmLocalScriptEngineFactory.
Issue: SPR-15059
Needed for Kotlin script and JSR 223 support, and a good target
for Spring Framework 5.0 since it will allow features like generating
Java 8 bytecode, JDK 9 support, annotation array attribute single
value without arrayOf(), etc.
We ensure Kotlin 1.0 compatibility by setting apiVersion and
languageVersion compiler options to 1.0.
Issue: SPR-15059
When connecting with a ReconnectStrategy we can only report the outcome
of the first connect to the ListenableFuture<Void> return value.
Failures for all subsequent attempts to reconnect however must be
channeled to TcpConnectHandler#afterConnectFailure which is used in
the STOMP broker relay for example to publish
BroadcastAvailability(true/false) events.
When decoding STOMP messages unread portions of a given input ByteBuf
must be kept until more input is received and the next complete STOMP
frame can be parsed.
In Reactor Net 2.x this was handled for us through the "remainder"
field in NettyChannelHandlerBridge. The Reactor Netty 0.6 upgrade
however applied only a simple map operator on the input ByteBuf
after which the buffer is relased.
This commit replaces the use of a simple map operator for decoding
and installs a ByteToMessageDecoder in the Netty channel pipeline
which has a built-in ability to preserve and merge unread input into
subsequent input buffers.
reactor-netty-0.6.0.RELEASE on Maven Central depends on
reactor-ipc-0.6.0.RELEASE so no need for this repository anymore.
It may be needed to cleanup Gradle or Maven local cache
since preliminary version of reactor-netty-0.6.0.RELEASE
had a dependency on reactor-ipc-0.6.0.BUILD-SNAPSHOT.
This commit removes the statically created XnioWorker which is an
"active" component and should not be created automatically and could
lead to resource leaks. Instead XnioWorker is now required at
construction aligning better with WebSocketClient#connectionBuilder
which also does not have a "default" worker option.
Since the XnioWorker is the main input for creating a ConnectionBuilder
we now create the ConnectionBuider in a protected method and then allow
a Consumer<ConnectionBuilder> to configure it further as opposed to the
Function<URI, ConnectionBuilder> used previously.
This commit also removes default SSL context initialization for RxNetty
to better align with other client implementations.
Issue: SPR-14527
Sebastien Deleuze
Juergen Hoeller
Mark Hobson
Sam Brannen
Brian Clozel
Stephane Nicoll
Gary Russell
Christoph Dreis
Philippe Marschall
Rob Winch
Rossen Stoyanchev