We should no longer rely on MYISAM for the sequence table since this
engine might not always be available. After this change the storage
engine used by the sequence table can be MYISAM or INNODB since the
sequences are allocated using a new connection without being
affected by any other transactions that might be in progress.
To allow users to fall back on the original functionality of using
MYISAM tables for the incrementer, we add a `useNewConnection` flag to
indicate whether or not to use a new connection for the incrementer.
This flag defaults to true.
Issue: SPR-15107
This commit introduces a router DSL for RouterFunctions
and RouterFunction in order to be able to write idiomatic
Kotlin code as below:
fun route(request: ServerRequest) = RouterFunctionDsl {
accept(TEXT_HTML).apply {
(GET("/user/") or GET("/users/")) { findAllView() }
GET("/user/{login}") { findViewById() }
}
accept(APPLICATION_JSON).apply {
(GET("/api/user/") or GET("/api/users/")) { findAll() }
POST("/api/user/") { create() }
POST("/api/user/{login}") { findOne() }
}
} (request)
Issue: SPR-15065
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
