Prior to this commit, it was possible to execute SQL scripts
programmatically via ResourceDatabasePopulator, JdbcTestUtils, and
ScriptUtils. Furthermore, it was also possible to execute SQL scripts
declaratively via the <jdbc> XML namespace. However, it was not
possible to execute SQL scripts declaratively on a per test class or
per test method basis.
This commit makes it possible to declaratively configure SQL scripts
for execution in integration tests via annotations that can be declared
at the class or method level. Details follow.
- Introduced a repeatable @DatabaseInitializer annotation that can be
used to configure SQL scripts at the class or method level with
method-level overrides. @DatabaseInitializers serves as a container
for @DatabaseInitializer.
- Introduced a new DatabaseInitializerTestExecutionListener that is
responsible for parsing @DatabaseInitializer and
@DatabaseInitializers and executing SQL scripts.
- DatabaseInitializerTestExecutionListener is registered by default in
abstract base test classes as well as in TestContextBootstrapper
implementations.
- @DatabaseInitializer and @DatabaseInitializers may be used as
meta-annotations; however, attribute overrides are not currently
supported for repeatable annotations used as meta-annotations. This
is a known limitation of Spring's AnnotationUtils.
- The semantics for locating SQL script resources is consistent with
@ContextConfiguration's semantics for locating XML configuration
files. In addition, a default SQL script can be detected based
either on the name of the annotated class or on the name of the
annotated test method.
- @DatabaseInitializer allows for specifying which DataSource and
PlatformTransactionManager to use from the test's
ApplicationContext, including default conventions consistent with
TransactionalTestExecutionListener and @TransactionConfiguration.
- @DatabaseInitializer supports all of the script configuration options
currently supported by ResourceDatabasePopulator.
- @DatabaseInitializer and DatabaseInitializerTestExecutionListener
support execution phases for scripts that dictate when SQL scripts
are executed (i.e., before or after a test method).
- SQL scripts can be executed within the current test's transaction if
present, outside of the current test's transaction if present, or
always in a new transaction, depending on the value of the boolean
requireNewTransaction flag in @DatabaseInitializer.
- DatabaseInitializerTestExecutionListener delegates to
ResourceDatabasePopulator#execute to actually execute the scripts.
Issue: SPR-7655
This commit adds a SQLErrorCodes instance for SAP DB, based on a
contribution from Andrew Clemons
Mostly based on SAP Hana SPS 07 with a few additional codes that are
only present is previous versions:
* -813 - Cannot connect to host somehost:30115 [Connection refused]
* -709 - Unknown host somehost:30115 [somehost], -709.]
* -708 - Cannot connect to jdbc:sap://somehost:30115 [Receive of connect failed.]
* -11210 - Invalid column index XYZ.
Issue: SPR-11770
Animal sniffer provides tools to assist verifying that classes
compiled with a newer JDK are compatible with an older JDK.
This integratesthe latest version of the tool (1.11) that
permits the use of custom annotations. Added @UsesJava7,
@UsesJava8 and @UsesSunHttpServer and annotated the few places
where we rely on a specific environment.
The verification process can be invoked by running the 'sniff'
task.
Issue: SPR-11604
polishing
Clean up compiler warnings in the tests of spring-jdbc. This commit
adds type parameters to all the types (mostly `List` and `Map`). In
addition it uses Java 5 autoboxing to get rid of all of the following
* new Integer
* new Long
* new Float
* new Double
* new Boolean
* new String
This should be unnoticeably faster since interning can be uses for
Integer and such.
After this commit the only warnings in spring-jdbc left are:
* raw type warning in `MapDataSourceLookupTests`, that code would never
compile with generics
* deprecation warning for `#queryForInt` and `#queryForLong`
Prior to this commit it was impossible to add additional scripts to a
ResourceDatabasePopulator after setScripts() had been invoked.
This commit fixes this by ensuring that the internal scripts list
continues to be modifiable when setScripts() is invoked.
Issue: SPR-11691
Prior to this commit ResourceDatabasePopulator did not assert any
preconditions for constructor and method arguments. Consequently,
errors would not be encountered until the populator was executed.
This commit addresses this issue by ensuring that preconditions for
constructor and method arguments are asserted immediately, throwing
IllegalArgumentExceptions where appropriate.
Issue: SPR-11690
Changed the value of ScriptUtils.EOF_STATEMENT_SEPARATOR from
"<<< END OF SCRIPT >>>" to "^^^ END OF SCRIPT ^^^" so that the angle
brackets do not have to be escaped in XML configuration files.
Issue: SPR-11687
Prior to Spring Framework 4.0.3, it was possible to supply a bogus
statement separator (i.e., a separator string that does not exist in
the configured SQL scripts) to ResourceDatabasePopulator with the side
effect that the entire contents of a script file would be interpreted
as a single SQL statement.
This undocumented feature was never intentional; however, some
developers came to rely on it. Unfortunately, changes made in
conjunction with SPR-9531 and SPR-11560 caused such scenarios to no
longer work.
This commit introduces first-class support for executing scripts which
contain a single statement that spans multiple lines but is not
followed by an explicit statement separator.
Specifically, ScriptUtils.EOF_STATEMENT_SEPARATOR may now be specified
as a 'virtual' statement separator to denote that a script contains a
single statement and no actual separator.
Issue: SPR-11687
To simplify common use cases, this commit introduces a new
execute(DataSource) method in ResourceDatabasePopulator that complements
the existing populate(Connection) method.
Issue: SPR-11629
Prior to this commit, the codebase was using a mix of log4j.xml
and log4j.properties for test-related logging configuration. This
can be an issue as log4j takes the xml variant first when looking
for a default bootstrap configuration.
In practice, some modules declaring the properties variant were
taking the xml variant configuration from another module.
The general structure of the configuration has also been
harmonized to provide a standard console output as well as an
easy way to enable trace logs for the current module.
This commit sets the DB_CLOSE_ON_EXIT flag to false for embedded H2
databases loaded using H2EmbeddedDatabaseConfigurer (i.e., via Spring's
<jdbc:embedded-database /> XML namespace, EmbeddedDatabaseBuilder,
EmbeddedDatabaseFactory, and EmbeddedDatabaseFactoryBean).
Issue: SPR-11573
This commit improves the configurability of EmbeddedDatabaseBuilder by
exposing the following new configuration methods.
- setDataSourceFactory(DataSourceFactory)
- addScripts(String...)
- setScriptEncoding(String)
- setSeparator(String)
- setCommentPrefix(String)
- setBlockCommentStartDelimiter(String)
- setBlockCommentEndDelimiter(String)
- continueOnError(boolean)
- ignoreFailedDrops(boolean)
If more fine grained control over the configuration of the embedded
database is required, users are recommended to use
EmbeddedDatabaseFactory with a ResourceDatabasePopulator and forego use
of the builder.
Issue: SPR-11410
In ScriptUtils and related classes, SQLExceptions are now caught and
wrapped in ScriptExceptions wherever feasible.
Affected "throws" declarations have also been revised as appropriate.
Issue: SPR-11564
This commit continues the work began in SPR-9531 as follows.
- ScriptException now extends DataAccessException.
- DatabasePopulator.populate() now explicitly throws ScriptException.
- Introduced UncategorizedScriptException.
- DatabasePopulatorUtils.execute() now throws an
UncategorizedScriptException instead of a
DataAccessResourceFailureException.
Issue: SPR-11564
