Sam Brannen

Introduce BEFORE METHOD/CLASS modes in @DirtiesContext

Prior to this commit, @DirtiesContext could only be used to close a

test ApplicationContext after an entire test class or after a test

method; however, there are some use cases for which it would be

beneficial to close a test ApplicationContext before a given test class

or test method – for example, if some rogue (i.e., yet to be

determined) test within a large test suite has corrupted the original

configuration for the ApplicationContext.

This commit provides a solution to such testing challenges by

introducing the following modes for @DirtiesContext.

  • MethodMode.BEFORE_METHOD: configured via the new methodMode attribute

  • ClassMode.BEFORE_CLASS and ClassMode.BEFORE_EACH_TEST_METHOD: both

    configured via the existing classMode attribute

Issue: SPR-12429

Polish Javadoc for TestContext

Add tests that use the new generate-name attribute

This commit updates the Spr8849Tests test suite to include XML

configuration that guarantees that a unique database name is always

automatically generated (via the new 'generate-name' attribute that was

introduced in SPR-8849) while reusing the same bean name (i.e.,

'dataSource').

Issue: SPR-8849

Support unique names for embedded databases

Development teams often encounter errors with embedded databases if

their test suite inadvertently attempts to recreate additional

instances of the same database. This can happen quite easily if an XML

configuration file or @Configuration class is responsible for creating

an embedded database and the corresponding configuration is then reused

across multiple testing scenarios within the same test suite (i.e.,

within the same JVM process) – for example, integration tests against

embedded databases whose ApplicationContext configuration only differs

with regard to which bean definition profiles are active.

The root cause of such errors is the fact that Spring's

EmbeddedDatabaseFactory (used internally by both the

<jdbc:embedded-database> XML namespace element and the

EmbeddedDatabaseBuilder for Java Config) will set the name of the

embedded database to "testdb" if not otherwise specified. For the case

of <jdbc:embedded-database>, the embedded database is typically

assigned a name equal to the bean's id. Thus, subsequent attempts to

create an embedded database will not result in a new database. Instead,

the same JDBC connection URL will be reused, and attempts to create a

new embedded database will actually point to an existing embedded

database created from the same configuration.

This commit addresses this common issue by introducing support for

generating unique names for embedded databases. This support can be

enabled via:

  • EmbeddedDatabaseFactory.setGenerateUniqueDatabaseName()

  • EmbeddedDatabaseBuilder.generateUniqueName()

  • <jdbc:embedded-database generate-name="true" ... >

Issue: SPR-8849

Refactor tests to use the new database-name attribute

This commit refactors the XML configuration used by the tests in the

Spr8849Tests test suite so that a unique database name is always

generated (via the new 'database-name' attribute that was introduced in

SPR-12835) while reusing the same bean name (i.e., 'dataSource').

This is a much more robust alternative to the previous work-around

since the name of the DataSource does not randomly change across

application contexts, thus allowing proper autowiring by name and bean

referencing within XML configuration.

Issue: SPR-8849

Introduce database-name in <jdbc:embedded-database>

Prior to this commit, the EmbeddedDatabaseBeanDefinitionParser set the

name of the embedded database that it configured to the value of its

'id'. This made it impossible to assign unique names to embedded

databases if the same bean 'id' (e.g, 'dataSource') was used across

multiple application contexts loaded within the same JVM, which is

often the case within an integration test suite. In contrast, the

EmbeddedDatabaseBuilder already provides support for setting the name

in Java Config. Thus there is a disconnect between XML and Java

configuration.

This commit addresses this issue by introducing a 'database-name'

attribute in <jdbc:embedded-database />. This allows developers to set

unique names for embedded databases – for example, via a SpEL

expression or a property placeholder that is influenced by the current

active bean definition profiles.

Issue: SPR-12835

Allow <jdbc:embedded-database> to be declared w/o id

This commit modifies EmbeddedDatabaseBeanDefinitionParser so that the

<jdbc:embedded-database> XML namespace element can be declared as an

anonymous bean (i.e., without an explicit ID).

Issue: SPR-12834

Introduce spring-jdbc-4.2.xsd

This commit introduces spring-jdbc-4.2.xsd in order to support upcoming

changes to the JDBC XML namespace.

In addition, this commit polishes the XSD documentation with regard to

use cases for script execution.

Polish Javadoc in MutablePersistenceUnitInfo

  • Using Javadoc syntax for code formatting instead of JIRA's.

Ensure WebSocketStompClientTests compiles in Gradle build as well

Polish GroovyBeanDefinitionReader ctr Javadoc

Clean up & suppress warnings in spring-messaging

Ensure WebSocketStompClientTests compiles in STS 3.6.4

Delete unused imports in spring-messaging

Polish AnnotationAwareOrderComparator

Delete unused method in TypeDescriptor

Support @NumberFormat as a meta-annotation

This commit ensures that @NumberFormat can be used as a

meta-annotation, as was already the case for @DateTimeFormat.

In addition, this commit polishes FormattingConversionServiceTests and

MvcNamespaceTests.

Issue: SPR-12743

(backported from commits df1d90f & c3408d8)

Remove trailing whitespace in source code

  1. … 8 more files in changeset.

Merge pull request #741 from kazuki43zoo/SPR-12743

  • SPR-12743:

    Support @NumberFormat as a meta-annotation

Assemble iajc Ant task classpath w/ folders that exist

Prior to this commit, the [ant:iajc] tasks logged numerous warnings

regarding incorrect classpath entries. The reason is that the classpath

was constructed with paths that do not physically exist in the file

system (e.g., for projects that do not have test classes or test

folders (yet)).

This commit picks up where ef75bd8 left off and addresses this issue by

assembling the runtime classpath passed to the iajc task with folders

and JARs that actually exist in the filesystem.

Assume TestGroup.PERFORMANCE for AnnotationProcessorPerformanceTests

This commit applies the TestGroup.PERFORMANCE assumption for all test

methods within AnnotationProcessorPerformanceTests.

Remove Gradle Daemon JVM args compatible with JDK 9

This commit reverts the changes made in 7bc44a9 so that developers who

do not use the Gradle daemon are not adversely affected by the explicit

JVM args that were introduced in that commit.

Developers who wish to run the build against JDK 9 with the Gradle

daemon can add the following to the gradle.properties file in their

'gradle user home' directory (e.g., ~/.gradle/gradle.properties):

org.gradle.daemon=true

org.gradle.jvmargs=-XX:MaxMetaspaceSize=1024m -Xmx1024m

See also: https://issues.gradle.org/browse/GRADLE-3256

Issue: SPR-12549

Set Gradle Daemon JVM args compatible with JDK 9

This commit adds the following to gradle.properties in order to execute

the Gradle daemon on JDK 9, since Gradle's DaemonParameters

automatically sets the MaxPermSize JVM argument, which is no longer

supported on JDK 9.

org.gradle.jvmargs=-XX:MaxMetaspaceSize=1024m -Xmx1024m

Issue: SPR-12549

Simplify Groovy ContextLoaders in the TCF

This commit simplifies the implementations of loadBeanDefinitions() in

GenericGroovyXmlContextLoader and GenericGroovyXmlWebContextLoader.

Due to the recent bug fix for GroovyBeanDefinitionReader regarding full

support for XML config files, these Groovy context loaders can now

simply use a GroovyBeanDefinitionReader instead of a

GroovyBeanDefinitionReader plus an XmlBeanDefinitionReader.

Issue: SPR-12769

Fully support XML config in GroovyBeanDefinitionReader

Prior to this commit, the GroovyBeanDefinitionReader claimed (via its

Javadoc) that it fully supported XML configuration files in addition to

its Groovy DSL; however, this was unfortunately inaccurate since XML

validation was disabled by default which led to certain features of XML

configuration not working. For example, it was impossible to define a

<qualifier> in an XML config file without specifying the 'type'

attribute (which has a default value defined in the spring-beans XSD).

This commit fixes this issue by ensuring that bean definitions in XML

resources are loaded with a "standard" XmlBeanDefinitionReader that is

created with default settings (i.e., with XML validation enabled). With

regard to backwards compatibility, bean definitions defined using the

Groovy DSL are still loaded with an XmlBeanDefinitionReader that has

XML validation disabled by default which is necessary for proper

parsing of the Groovy DSL.

Issue: SPR-12769

(cherry picked from commit 7edc7c2c8f3e98a9c61d4c9520489d132c00e0a0)

Fully support XML config in GroovyBeanDefinitionReader

Prior to this commit, the GroovyBeanDefinitionReader claimed (via its

Javadoc) that it fully supported XML configuration files in addition to

its Groovy DSL; however, this was unfortunately inaccurate since XML

validation was disabled by default which led to certain features of XML

configuration not working. For example, it was impossible to define a

<qualifier> in an XML config file without specifying the 'type'

attribute (which has a default value defined in the spring-beans XSD).

This commit fixes this issue by ensuring that bean definitions in XML

resources are loaded with a "standard" XmlBeanDefinitionReader that is

created with default settings (i.e., with XML validation enabled). With

regard to backwards compatibility, bean definitions defined using the

Groovy DSL are still loaded with an XmlBeanDefinitionReader that has

XML validation disabled by default which is necessary for proper

parsing of the Groovy DSL.

Issue: SPR-12769

Polish Javadoc for GroovyBeanDefinitionReader

Polish Javadoc for GroovyBeanDefinitionReader

Support XML config fully in web integration tests

Prior to this commit, it was impossible to use all features of XML

configuration (e.g., the <qualifier> tag) in web-based integration

tests (loaded using @WebAppConfiguration, @ContextConfiguration, etc.)

if the Groovy library was on the classpath. The reason is that the

GroovyBeanDefinitionReader used internally by

GenericGroovyXmlWebContextLoader disables XML validation for its

internal XmlBeanDefinitionReader, and this prevents some XML

configuration features from working properly. For example, the default

value for the 'type' attribute (defined in the spring-beans XSD) of the

<qualifier> tag gets ignored, resulting in an exception when the

application context is loaded.

This commit addresses this issue by refactoring the implementation of

loadBeanDefinitions() in GenericGroovyXmlWebContextLoader to use an

XmlBeanDefinitionReader or GroovyBeanDefinitionReader depending on the

file extension of the resource location from which bean definitions

should be loaded. This aligns the functionality of

GenericGroovyXmlWebContextLoader with the existing functionality of

GenericGroovyXmlContextLoader.

Issue: SPR-12768

(cherry picked from commit 2ba1151b7fa3fcd3b0c964fc377ce57671eabb8b)

Support XML config fully in web integration tests

Prior to this commit, it was impossible to use all features of XML

configuration (e.g., the <qualifier> tag) in web-based integration

tests (loaded using @WebAppConfiguration, @ContextConfiguration, etc.)

if the Groovy library was on the classpath. The reason is that the

GroovyBeanDefinitionReader used internally by

GenericGroovyXmlWebContextLoader disables XML validation for its

internal XmlBeanDefinitionReader, and this prevents some XML

configuration features from working properly. For example, the default

value for the 'type' attribute (defined in the spring-beans XSD) of the

<qualifier> tag gets ignored, resulting in an exception when the

application context is loaded.

This commit addresses this issue by refactoring the implementation of

loadBeanDefinitions() in GenericGroovyXmlWebContextLoader to use an

XmlBeanDefinitionReader or GroovyBeanDefinitionReader depending on the

file extension of the resource location from which bean definitions

should be loaded. This aligns the functionality of

GenericGroovyXmlWebContextLoader with the existing functionality of

GenericGroovyXmlContextLoader.

Issue: SPR-12768