- 25 7月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
-
- 24 7月, 2014 2 次提交
-
-
由 Sam Brannen 提交于
Spring Framework 4.0 introduced first-class support for a Groovy-based DSL for defining the beans for an ApplicationContext. However, prior to this commit, the Spring TestContext Framework (TCF) did not provide any out-of-the-box support for using Groovy scripts as path-based resource locations when loading an application context for tests. This commit addresses this issue by introducing first-class support for using Groovy scripts to load the ApplicationContext for integration tests managed by the TCF. Specifically, the following changes have been made in the TCF to support Groovy scripts. - Introduced getResourceSuffixes() in AbstractContextLoader in order to support multiple resource suffixes in the default detection process. This feature is used by the new Groovy/Xml context loaders. - Introduced GenericGroovyXmlContextLoader and GenericGroovyXmlWebContextLoader which support both Groovy scripts and XML config files for loading bean definitions. Furthermore, these loaders support "-context.xml" and "Context.groovy" as resource suffixes when detecting defaults. Note that a default XML config file will be detected before a default Groovy script. - DelegatingSmartContextLoader and WebDelegatingSmartContextLoader now use reflection to choose between using GenericGroovyXmlContextLoader and GenericGroovyXmlWebContextLoader vs. GenericXmlContextLoader and GenericXmlWebContextLoader as their XML loaders, depending on whether Groovy is present in the classpath. - Groovy scripts can be configured via the 'locations' or 'value' attributes of @ContextConfiguration and can be mixed seamlessly with XML config files. Issue: SPR-11233
-
由 Sam Brannen 提交于
- Formatting - Suppress warnings - Remove unused imports
-
- 23 7月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This is a follow-up on the commit introducing MockMvcConfigurer: https://github.com/spring-projects/spring-framework/commit/c2b0fac852dd9f865699fb374ad78543767fec05 This commit refines the MockMvcConfigurer contract to use (the new) ConfigurableMockMvcBuilder hence not requiring downcasting to AbstractMockMvcBuilder. The same also no longer passes the "default" RequestBuilder which would also require a downcast, but rather allows a RequestPostProcessor to be returned so that a 3rd party framework or application can modify any property of every performed MockHttpServletRequest. To make this possible the new SmartRequestBuilder interface separates request building from request post processing while the new ConfigurableSmartRequestBuilder allows adding a RequestPostProcessor to a MockMvcBuilder. Issue: SPR-11497
-
- 21 7月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
-
- 19 7月, 2014 4 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Overhauled class-level Javadoc for TransactionalTestExecutionListener: - Reorganized content. - Added headings to paragraphs. - Documented TestTransaction support. Issue: SPR-11941
-
- 18 7月, 2014 6 次提交
-
-
由 Sam Brannen 提交于
-
由 Juergen Hoeller 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Prior to this commit, the support for SQL script execution via @Sql provided an algorithm for looking up a required PlatformTransactionManager to use to drive transactions. However, a transaction manager is not actually required for all testing scenarios. This commit improves the transaction management support for @Sql so that SQL scripts can be executed without a transaction if a transaction manger is not present in the ApplicationContext. The updated algorithm now supports the following use cases. - If a transaction manager and data source are both present (i.e., explicitly specified via the transactionManager and dataSource attributes of @SqlConfig or implicitly discovered in the ApplicationContext based on conventions), both will be used. - If a transaction manager is not explicitly specified and not implicitly discovered based on conventions, SQL scripts will be executed without a transaction but requiring the presence of a data source. If a data source is not present, an exception will be thrown. - If a data source is not explicitly specified and not implicitly discovered based on conventions, an attempt will be made to retrieve it by using reflection to invoke a public method named getDataSource() on the transaction manager. If this attempt fails, an exception will be thrown. - If a data source can be retrieved from the resolved transaction manager using reflection, an exception will be thrown if the resolved data source is not the data source associated with the resolved transaction manager. This helps to avoid possibly unintended configuration errors. - If @SqlConfig.transactionMode is set to ISOLATED, an exception will be thrown if a transaction manager is not present. Issue: SPR-11911
-
- 17 7月, 2014 3 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
- 16 7月, 2014 4 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Prior to this commit, @Sql provided attributes for configuring the syntax of the referenced SQL scripts as well as exception handling and transaction behavior; however, such configuration could not be reused across @Sql declarations thus requiring developers to copy-and-paste common configuration and resulting in unnecessary code duplication. This commit addresses this issue by introducing a new @SqlConfig annotation that can be used to declare common, global configuration for SQL scripts that can be reused within a test class hierarchy. - Introduced top-level @SqlConfig annotation and extracted common configuration attributes from @Sql. - @SqlConfig can be used at the class level for common, global config or via the new 'config' attribute of @Sql for local config. - Introduced MergedSqlConfig as a holder for the merged values from local and global @SqlConfig instances. MergedSqlConfig also contains the logic for overriding global configuration with local configuration. - Refactored all attributes of @SqlConfig to be either of type String or custom enums in order to support overriding. Empty Strings or DEFAULT enum values imply the use of a default or inherited value. Issue: SPR-11896
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11497
-
- 11 7月, 2014 1 次提交
-
-
由 Lea Farmer 提交于
This change adds a method within the ModelResultMatcher that will allow a user to assert whether the returned Model has an attribute with a field that has a specific error associated with it. Issue: SPR-11971
-
- 10 7月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 03 7月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
Historically, Spring's JUnit 3.8 TestCase class hierarchy supported programmatic transaction management of "test-managed transactions" via the protected endTransaction() and startNewTransaction() methods in AbstractTransactionalSpringContextTests. The Spring TestContext Framework (TCF) was introduced in Spring 2.5 to supersede the legacy JUnit 3.8 support classes; however, prior to this commit the TCF has not provided support for programmatically starting or stopping the test-managed transaction. This commit introduces a TestTransaction class in the TCF that provides static utility methods for programmatically interacting with test-managed transactions. Specifically, the following features are supported by TestTransaction and its collaborators. - End the current test-managed transaction. - Start a new test-managed transaction, using the default rollback semantics configured via @TransactionConfiguration and @Rollback. - Flag the current test-managed transaction to be committed. - Flag the current test-managed transaction to be rolled back. Implementation Details: - TransactionContext is now a top-level, package private class. - The existing test transaction management logic has been extracted from TransactionalTestExecutionListener into TransactionContext. - The current TransactionContext is stored in a NamedInheritableThreadLocal that is managed by TransactionContextHolder. - TestTransaction defines the end-user API, interacting with the TransactionContextHolder behind the scenes. - TransactionalTestExecutionListener now delegates to TransactionContext completely for starting and ending transactions. Issue: SPR-5079
-
- 02 7月, 2014 1 次提交
-
-
由 Sebastien Deleuze 提交于
Based on the JSONassert library. Issue: SPR-10113
-
- 01 7月, 2014 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Issue: SPR-11822
-
- 28 6月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-1822
-
- 26 6月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 25 6月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, the Spring TestContext Framework (TCF) was compatible with JUnit 4.5 or higher. This commit effectively raises the minimum version of JUnit that is officially supported by the TCF to JUnit 4.9, thereby aligning with similar upgrades made in the Spring Framework 4.0 release (i.e., upgrading minimum requirements on third-party libraries to versions released mid 2010 or later). Issue: SPR-11908
-
- 20 6月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, SQL script annotations and related classes in the TestContext framework (TCF) were named DatabaseInitializer*. However, these annotations are not used only for initialization and are therefore misleading when used for cleaning up the database. This commit refines the names of annotations and related classes for configuring SQL scripts to be executed for integration tests in the TCF as follows: - @DatabaseInitializer -> @Sql - @DatabaseInitializers -> @SqlGroup - DatabaseInitializerTestExecutionListener -> SqlScriptsTestExecutionListener A special thanks goes out to the following attendees of the Zurich Hackergarten meeting last night for their collective brainstorming: @aalmiray, @atsticks, @ollin, @simkuenzi, @tangresh, @vyazelenko. Issue: SPR-7655
-
- 11 6月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11854
-
- 06 6月, 2014 3 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11764
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
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
-
- 20 5月, 2014 3 次提交
-
-
由 Juergen Hoeller 提交于
Consistent use of IllegalStateException instead of InternalError for UnsupportedEncodingException cause
-
由 Juergen Hoeller 提交于
Consistently log Class.getName() instead of Class.toString(), avoiding double class term in log message Issue: SPR-11804
-
由 Juergen Hoeller 提交于
Consistently log Class.getName() instead of Class.toString(), avoiding double class term in log message Issue: SPR-11804
-
- 19 5月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-11804
-