This commit introduces SqlServerSequenceMaxValueIncrementer to support
SQL Server sequences, complementing the existing
SqlServerMaxValueIncrementer for table-based support.
Closes gh-29447
SQLErrorCodeSQLExceptionTranslator#USER_PROVIDED_ERROR_CODES_FILE_PRESENT
evaluation at build time combined with the lazy
SQLErrorCodesFactory#instance initialization allow to
avoid making SQLErrorCodesFactory constructor reachable
when no custom sql-error-codes.xml is provided.
Closes gh-29294
This commit also removes ResourcePropertiesPersister which
was introduced in 5.3 specifically for spring.xml.ignore
flag and which is expected to be used only internally by
Spring Framework. DefaultPropertiesPersister should be used
instead.
Closes gh-29277
This commit adds a reflection hint on
EmbeddedDatabaseFactory$EmbeddedDataSourceProxy#shutdown when
EmbeddedDatabaseFactory is reachable in order to allow its usage
as bean destroy method.
Closes gh-29259
As of Java 18, the serial lint warning in javac has been expanded to
check for class fields that are not marked as `Serializable`.
See https://www.oracle.com/java/technologies/javase/18all-relnotes.html#JDK-8202056
In the Spring Framework codebase, this can happen with `Map`, `Set` or
`List` attributes which are often assigned with an unmodifiable
implementation variant. Such implementations are `Serializable` but
cannot be used as field types.
This commit ensures that the following changes are applied:
* fields are marked as transient if they can't be serialized
* classes are marked as `Serializable` if this was missing
* `@SuppressWarnings("serial")` is applied where relevant
These tests often fail on the CI server and do not provide any
meaningful information when they fail, since only a proper benchmark
would suffice. Furthermore, the test method was introduced 10 years
ago to address deficiencies in JDK 7 which no longer exist.
See gh-14415
Prior to this commit, the `ConcurrentLruCache` implementation would not
perform well under certain conditions. As long as the cache capacity was
not reached, the cache would avoid maintaining an eviction queue
(reordering entries depending with least/most recently read). When the
cache capacity was reached, the LRU queue was updated for each
read/write operation. This decreased performance significantly under
contention when the capacity was reached.
This commit completely rewrites the internals of `ConcurrentLruCache`.
`ConcurrentLruCache` is now a specialized version of the
`ConcurrentLinkedHashMap` [1]. This change focuses on buferring read and
write operations, only processing them at certain times to avoid
contention.
When a cached entry is read, a read operation is queued and buffered
operations are drained if the buffer reached a fixed limit. When a new
cache entry is added or removed, a write operation is queued and
triggers a drain attempt. When the capacity is outgrown, the cache polls
items from the eviction queue, which maintains elements with the
least recently used ones first. Entries are removed until the capacity
is under control.
The behavior described here and the buffer sizes are optimized with the
number of available processors in mind. Work is localized as much as
possible on a per-thread basis to avoid contention on the eviction queue.
The new implementation has been tested with the JMH benchmark provided
here, comparing the former `COncurrentLruCache`, the new implementation
as well as the `ConcurrentLinkedHashMap` [1].
When testing with a cache reaching capacity, under contention, with a
10% cache miss, we're seeing a 40x improvement compared to the previous
implementation and performance on par with the reference.
See [2] for how to replicate the benchmark.
[1] https://github.com/ben-manes/concurrentlinkedhashmap
[2] https://github.com/spring-projects/spring-framework/wiki/Micro-Benchmarks
Closes gh-26320
Align IllegalStateException with SQLException handling and propagate
the original exception.
See gh-28669
Co-authored-by: Christoph Mies <chr.mi@web.de>
SQLErrorCodeSQLExceptionTranslator kicks in for user-provided sql-error-codes.xml files. It will still pick up Spring's legacy default error code mappings as well but only when triggered by a (potentially empty) user-provided file in the root of the classpath.
Closes gh-28216
Commit 6316a35 introduced a regression for property names starting with
multiple uppercase letters (such as setEMail(...)).
This commit fixes that regression and includes an additional test to
cover this case.
See gh-27929
Closes gh-27941
@hpoettker made me aware of the ModeEnum in H2 that allows the
parameterized test to be simplified, which was the primary impetus for
this commit.
See gh-27870
Prior to this commit, H2SequenceMaxValueIncrementer only supported H2
database 1.4.
This commit updates H2SequenceMaxValueIncrementer's getSequenceQuery()
method so that the syntax used supports version 1.4 and 2.0 of the H2
database.
This commit also updates several test schemas so that they work with H2
1.4 and 2.0 as well as HSQL.
Closes gh-27870
This commit fixes the Javadoc in all queryForObject(...) methods in
JdbcOperations and NamedParameterJdbcOperations regarding what kinds of
exceptions are thrown under which conditions.
Closes gh-27559
Prior to this commit, DatabasePopulatorUtils.execute(...) did not
perform a commit for the current Connection. This works for most use
cases; however, when DatabasePopulatorUtils is used to execute
initialization scripts without a managed transaction -- for example,
via a DataSourceInitializer configured as a bean in the
ApplicationContext or via Spring Boot configuration in
application.properties -- if the underlying database is configured with
auto-commit=false, the results of executing the SQL scripts are not
committed to the database which can lead to data being silently lost.
This commit addresses this issue by committing the Connection for the
supplied DataSource if the connection is not configured for auto-commit
and is not transactional. Existing use cases running with a managed
transaction should therefore not be affected by this change.
Closes gh-27008
In order to catch Javadoc errors in the build, we now enable the
`Xwerror` flag for the `javadoc` tool. In addition, we now use
`Xdoclint:syntax` instead of `Xdoclint:none` in order to validate
syntax within our Javadoc.
This commit fixes all resulting Javadoc errors and warnings.
This commit also upgrades to Undertow 2.2.12.Final and fixes the
artifact names for exclusions for the Servlet and annotations APIs.
The incorrect exclusion of the Servlet API resulted in the Servlet API
being on the classpath twice for the javadoc task, which resulted in the
following warnings in previous builds.
javadoc: warning - Multiple sources of package comments found for package "javax.servlet"
javadoc: warning - Multiple sources of package comments found for package "javax.servlet.http"
javadoc: warning - Multiple sources of package comments found for package "javax.servlet.descriptor"
javadoc: warning - Multiple sources of package comments found for package "javax.servlet.annotation"
Closes gh-27480
In order to be able to use text blocks and other new Java language
features, we are upgrading to a recent version of Checkstyle.
The latest version of spring-javaformat-checkstyle (0.0.28) is built
against Checkstyle 8.32 which does not include support for language
features such as text blocks. Support for text blocks was added in
Checkstyle 8.36.
In addition, there is a binary compatibility issue between
spring-javaformat-checkstyle 0.0.28 and Checkstyle 8.42. Thus we cannot
use Checkstyle 8.42 or higher.
In this commit, we therefore upgrade to spring-javaformat-checkstyle
0.0.28 and downgrade to Checkstyle 8.41.
This change is being applied to `5.3.x` as well as `main` in order to
benefit from the enhanced checking provided in more recent versions of
Checkstyle.
Closes gh-27481
To slightly improve performance, this commit switches to
StringBuilder.append(char) instead of StringBuilder.append(String)
whenever we append a single character to a StringBuilder.
Closes gh-27098
Many of the utility methods in ScriptUtils are public only because they
were once invoked from JdbdTestUtils in spring-test, which is no longer
the case. Consequently, there should no longer be a need for any
external clients to invoke such methods.
To address this, this commit formally deprecates the following methods
in ScriptUtils in spring-jdbc.
- readScript(...)
- containsSqlScriptDelimiters(...)
- splitSqlScript(...)
Closes gh-26947
Prior to this commit, the implementations of
ScriptUtils.containsSqlScriptDelimiters() in spring-jdbc and
spring-r2dbc did not ignore comments when searching for the statement
delimiter within an SQL script. This resulted in subtle bugs if a
comment contained a single single-quote or single double-quote, since
the absence of the closing single-quote or double-quote led the
algorithm to believe that it was still "within a text literal". Similar
issues could arise if a comment contained the sought statement
delimiter but the rest of the script did not contain the sought
statement delimiter. In such cases, the algorithms in ScriptUtils could
erroneously choose an incorrect statement delimiter -- for example,
using the fallback statement delimiter instead of the delimiter
specified by the user.
This commit avoids such bugs by ignoring single-line comments and block
comments when searching for the statement delimiter within an SQL
script.
Closes gh-26911
Prior to this commit, the containsSqlScriptDelimiters() method in
ScriptUtils ignored delimiters enclosed in single quotes but not those
enclosed within double quotes, which contradicts the algorithm in
splitSqlScript() and therefore constitutes a bug.
This commit fixes this bug in the ScriptUtils implementations in
spring-jdbc and spring-r2dbc.
Closes gh-26935
Prior to this commit, MySQLMaxValueIncrementer could not be used when
the MySQL database was configured to use safe-updates mode.
See https://dev.mysql.com/doc/refman/8.0/en/mysql-tips.html#safe-updates
This commit introduces a `limit 1` clause to the generated update
statement to allow MySQLMaxValueIncrementer to be compatible with
MySQL safe-updates mode.
Closes gh-26858
Prior to this commit, if an SQLException was thrown while retrieving
column metadata from the database, SimpleJdbcInsert would generate an
INSERT statement that was syntactically valid but missing columns,
which could lead to data silently missing in the database (for nullable
columns).
This commit fixes this by clearing all collected column metadata if an
SQLException is thrown while processing the metadata. The result is
that an InvalidDataAccessApiUsageException will be thrown later while
generating the INSERT statement. The exception message now contains an
additional hint to make use of SimpleJdbcInsert#usingColumns() in order
to ensure that all required columns are included in the generated
INSERT statement.
SimpleJdbcCall can also encounter an SQLException while retrieving
column metadata for a stored procedure/function, but an exception is
not thrown since a later invocation of the stored procedure/function
will likely fail anyway due to missing arguments. Consequently, this
commit only improves the warning level log message by including a hint
to make use of SimpleJdbcCall#addDeclaredParameter().
Closes gh-26486
This commit reverts some changes done in 2d5f9723fa
in order to fix JdbcOperations.queryForObject and
JdbcOperations.queryForList.
It is not possible to provide a vararg variant in Kotlin
for now due to a signature clash, but that will probably
make sense in Spring Framework 6 timeframe along to array
based variant removal for both Java and Kotlin.
Closes gh-26312
Prior to this commit, some tests would belong to the PERFORMANCE
`TestGroup`, while they were not testing for performance but rather
performing functional tests that involve long running operations or
timeouts.
This commit moves those tests to the LONG_RUNNING `TestGroup`.
See gh-24830
Includes deprecation of JdbcUtils.extractDatabaseMetaData(DataSource, String) in favor of the now generified version of extractDatabaseMetaData(DataSource, DatabaseMetaDataCallback).
Closes gh-25681
Closes gh-25686
MVC data class processor constructs target instance even in case of binding failure, as long as the corresponding method parameter is not marked as optional.
Closes gh-24372
- The compiler is configured to retain compatibility with Kotlin 1.3.
- Explicit API mode is not yet enabled but could be in the future.
- Some exceptions thrown by Kotlin have changed to NullPointerException,
see https://youtrack.jetbrains.com/issue/KT-22275 for more details.
Closes gh-24171
Prior to this commit the BeanPropertyRowMapper used
String.substring and String.toLowerCase to parse the
field names. This would generate more String than needed.
Instead one could iterate over the internal char[] of the
String and use the Character methods instead. This reduces
the String creation.
Closes gh-25301
- The compiler is configured to retain compatibility with Kotlin 1.3.
- Explicit API mode is not yet enabled but could be in the future.
- A workaround for Gradle build is required for now, see
https://youtrack.jetbrains.com/issue/KT-39610 for more details.
- Some exceptions thrown by Kotlin have changed to NullPointerException,
see https://youtrack.jetbrains.com/issue/KT-22275 for more details.
Closes gh-24171
Prior to this commit, the JDBC KeyHolder API only supported keys of
type Number. However, a generated key can be a UUID or something else,
and developers shouldn't have to go manually through complex
collections to access it.
This commit adds a new getKeyAs(Class<T> keyType) method to the
KeyHolder API that allows the user to specify the key type.
Closes gh-24655
Hi guys,
We're facing an issue in our application when we try to call a procedure in Informix database,
our app uses standard JDBC (spring-jdbc and com.ibm.informix.jdbc.4.50.3) without Hibernate
to connect to the database
Issue:
When we trying to execute any procedure call in our Informix database there is no data returned.
Diagnostic:
It points to the Java class called CallMetaDataProviderFactory in spring-jdbc project.
Taking a look of this class there is no explicit support for Informix procedure calls, so I added "Informix Dynamic Server" to the
list of supported databases and now I can execute procedures call without issues.
Basically I added the line "Informix Dynamic Server" to the list called "supportedDatabaseProductsForProcedures"
of CallMetaDataProviderFactory class in my local environment and it worked as expected.
I really appreciate any feedback/suggestion for this approach due we would like to continue using the framework
normally in our development without losing updates using a workaround in our end.
Many thanks in advance.
Prior to this commit, the Spring Framework build would partially use the
dependency management plugin to import and enforce BOMs.
This commit applies the dependency management plugin to all Java
projects and regroups all version management declaration in the root
`build.gradle` file (versions and exclusions).
Some versions are overridden in specific modules for
backwards-compatibility reasons or extended support.
This commit also adds the Gradle versions plugin that checks for
dependency upgrades in artifact repositories and produces a report; you
can use the following:
./gradlew dependencyUpdates
This commit reorganizes tasks and scripts in the build to only apply
them where they're needed. We're considering here 3 "types" of projects
in our build:
* the root project, handling documentation, publishing, etc
* framework modules (a project that's published as a spring artifact)
* internal modules, such as the BOM, our coroutines support and our
integration-tests
With this change, we're strealining the project configuration for all
spring modules and only applying plugins when needed (typically our
kotlin support).
See gh-23282
This commit removes the JUnit 4 dependency from all modules except
spring-test which provides explicit JUnit 4 support.
This commit also includes the following.
- migration from JUnit 4 assertions to JUnit Jupiter assertions in all
Kotlin tests
- migration from JUnit 4 assumptions in Spring's TestGroup support to
JUnit Jupiter assumptions, based on org.opentest4j.TestAbortedException
- introduction of a new TestGroups utility class than can be used from
existing JUnit 4 tests in the spring-test module in order to perform
assumptions using JUnit 4's Assume class
See gh-23451
Update `ResourceDatabasePopulator` and `ScriptUtils` so that more than
one comment prefix can be used when processing SQL scripts. This
feature is particularly useful when dealing with scripts provided by
Quartz since they often use a mix `--` and `#`.
Closes gh-23289
Sam Brannen
Kulwant Singh
Mahmoud Ben Hassine
Sam Brannen
Juergen Hoeller
Sébastien Deleuze
Johnny Lim
Marc Wrobel
Brian Clozel
ben-enfuse-io
Stephane Nicoll
Jiayi Li
Kevin Schönfeld
lijun695
Marten Deinum
Henning Poettker
a.yazychyan
Kazuki Shimizu
awgtek
Carsten Dimmek
Yanming Zhou
alexscari
Сергей Цыпанов
eXsio
Juergen Hoeller
Sam Brannen
Qimiao Chen
Hyunjin Choi
wilrosco
hyeonisism
perceptron8
Kwon Young Jae
康智冬
Phillip Webb
Brian Clozel
Sebastien Deleuze
Stephane Nicoll
zhuzhuman978