- 21 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
This commit introduces a convenience method in AnnotationUtils for synthesizing an annotation from its default attribute values. TransactionalTestExecutionListener has been refactored to invoke this new convenience method. Issue: SPR-13087
-
- 19 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
The initial support for synthesizing an annotation from a Map (or AnnotationAttributes) introduced in SPR-13067 required that the map contain key-value pairs for every attribute defined by the supplied annotationType. However, there are use cases that would benefit from being able to supply a reduced set of attributes and still have the annotation synthesized properly. This commit refines the validation mechanism in MapAnnotationAttributeExtractor so that a reduced set of attributes may be supplied. Specifically, if an attribute is missing in the supplied map the attribute will be set either to value of its alias (if an alias value configured via @AliasFor exists) or to the value of the attribute's default value (if defined), and otherwise an exception will be thrown. Furthermore, TransactionalTestExecutionListener has been refactored to take advantage of this new feature by synthesizing an instance of @TransactionConfiguration solely from the default values of its declared attributes. Issue: SPR-13087
-
- 14 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
In AnnotatedElementUtils, all methods pertaining to merging annotation attributes have been renamed to "getMerged*()" and "findMerged*()" accordingly. Existing methods such as getAnnotationAttributes(..) have been deprecated in favor of the more descriptive "merged" variants. This aligns the naming conventions in AnnotatedElementUtils with those already present in AnnotationReadingVisitorUtils. The use of "annotationType" as a variable name for the fully qualified class name of an annotation type has been replaced with "annotationName" in order to improve the readability and intent of the code base. In MetaAnnotationUtils.AnnotationDescriptor, getMergedAnnotation() has been renamed to synthesizeAnnotation(), and the method is now overridden in UntypedAnnotationDescriptor to always throw an UnsupportedOperationException in order to avoid potential run-time ClassCastExceptions. Issue: SPR-11511
-
- 29 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Spring Framework 4.2 RC1 introduced support for synthesizing an annotation from an existing annotation in order to provide additional functionality above and beyond that provided by Java. Specifically, such synthesized annotations provide support for @AliasFor semantics. As luck would have it, the same principle can be used to synthesize an annotation from any map of attributes, and in particular, from an instance of AnnotationAttributes. The following highlight the major changes in this commit toward achieving this goal. - Introduced AnnotationAttributeExtractor abstraction and refactored SynthesizedAnnotationInvocationHandler to delegate to an AnnotationAttributeExtractor. - Extracted code from SynthesizedAnnotationInvocationHandler into new AbstractAliasAwareAnnotationAttributeExtractor and DefaultAnnotationAttributeExtractor implementation classes. - Introduced MapAnnotationAttributeExtractor for synthesizing an annotation that is backed by a map or AnnotationAttributes instance. - Introduced a variant of synthesizeAnnotation() in AnnotationUtils that accepts a map. - Introduced findAnnotation(*) methods in AnnotatedElementUtils that synthesize merged AnnotationAttributes back into an annotation of the target type. The following classes have been refactored to use the new support for synthesizing AnnotationAttributes back into an annotation. - ApplicationListenerMethodAdapter - TestAnnotationUtils - AbstractTestContextBootstrapper - ActiveProfilesUtils - ContextLoaderUtils - DefaultActiveProfilesResolver - DirtiesContextTestExecutionListener - TestPropertySourceAttributes - TestPropertySourceUtils - TransactionalTestExecutionListener - MetaAnnotationUtils - MvcUriComponentsBuilder - RequestMappingHandlerMapping In addition, this commit also includes changes to ensure that arrays returned by synthesized annotations are properly cloned first. Issue: SPR-13067
-
- 20 5月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-12926
-
- 14 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
This commit updates code that previously used getAnnotationAttributes() in AnnotatedElementUtils to use findAnnotationAttributes(), where appropriate. Issue: SPR-12738
-
- 21 10月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 15 8月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, there was no declarative mechanism for a custom TestExecutionListener to be registered as a default TestExecutionListener. This commit introduces support for discovering default TestExecutionListener implementations via the SpringFactoriesLoader mechanism. Specifically, the spring-test module declares all core default TestExecutionListeners under the org.springframework.test.context.TestExecutionListener key in its META-INF/spring.factories properties file, and third-party frameworks and developers can contribute to the list of default TestExecutionListeners in the same manner. - AbstractTestContextBootstrapper uses the SpringFactoriesLoader to look up the class names of all registered default TestExecutionListeners and sorts the instantiated listeners using AnnotationAwareOrderComparator. - DefaultTestContextBootstrapper and WebTestContextBootstrapper now rely on the SpringFactoriesLoader mechanism for finding default TestExecutionListeners instead of hard coding fully qualified class names. - To ensure that default TestExecutionListeners are registered in the correct order, each can implement Ordered or declare @order. - AbstractTestExecutionListener and all default TestExecutionListeners provided by Spring now implement Ordered with appropriate values. - Introduced "copy constructors" in MergedContextConfiguration and WebMergedContextConfiguration - SpringFactoriesLoader now uses AnnotationAwareOrderComparator instead of OrderComparator. Issue: SPR-11466
-
- 07 8月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
-
- 25 7月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
-
- 19 7月, 2014 2 次提交
-
-
由 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 2 次提交
-
-
由 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
-
- 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
-
- 06 6月, 2014 1 次提交
-
-
由 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
-
- 17 1月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
This commit makes the logging in TransactionalTestExecutionListener consistent for both starting and ending transactions. Specifically, the current TestContext is now included in the informational log statement when starting a new transaction. Issue: SPR-11323
-
- 27 11月, 2013 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, the Spring TestContext Framework (TCF) supported the use of test-related annotations as meta-annotations for composing custom test stereotype annotations; however, attributes in custom stereotypes could not be used to override meta-annotation attributes. This commit addresses this by allowing attributes from the following annotations (when used as meta-annotations) to be overridden in custom stereotypes. - @ContextConfiguration - @ActiveProfiles - @DirtiesContext - @TransactionConfiguration - @Timed - @TestExecutionListeners This support depends on functionality provided by AnnotatedElementUtils. See the 'Notes' below for further details and ramifications. Notes: - AnnotatedElementUtils does not support overrides for the 'value' attribute of an annotation. It is therefore not possible or not feasible to support meta-annotation attribute overrides for some test-related annotations. - @ContextHierarchy, @WebAppConfiguration, @Rollback, @Repeat, and @ProfileValueSourceConfiguration define single 'value' attributes which cannot be overridden via Spring's meta-annotation attribute support. - Although @IfProfileValue has 'values' and 'name' attributes, the typical usage scenario involves the 'value' attribute which is not supported for meta-annotation attribute overrides. Furthermore, 'name' and 'values' are so generic that it is deemed unfeasible to provide meta-annotation attribute override support for these. - @BeforeTransaction and @AfterTransaction do not define any attributes that can be overridden. - Support for meta-annotation attribute overrides for @Transactional is provided indirectly via SpringTransactionAnnotationParser. Implementation Details: - MetaAnnotationUtils.AnnotationDescriptor now provides access to the AnnotationAttributes for the described annotation. - MetaAnnotationUtils.AnnotationDescriptor now provides access to the root declaring class as well as the declaring class. - ContextLoaderUtils now retrieves AnnotationAttributes from AnnotationDescriptor to look up annotation attributes for @ContextConfiguration and @ActiveProfiles. - ContextConfigurationAttributes now provides a constructor to have its attributes sourced from an instance of AnnotationAttributes. - ContextLoaderUtils.resolveContextHierarchyAttributes() now throws an IllegalStateException if no class in the class hierarchy declares @ContextHierarchy. - TransactionalTestExecutionListener now uses AnnotatedElementUtils to look up annotation attributes for @TransactionConfiguration. - Implemented missing unit tests for @Rollback resolution in TransactionalTestExecutionListener. - SpringJUnit4ClassRunner now uses AnnotatedElementUtils to look up annotation attributes for @Timed. - TestContextManager now retrieves AnnotationAttributes from AnnotationDescriptor to look up annotation attributes for @TestExecutionListeners. - DirtiesContextTestExecutionListener now uses AnnotatedElementUtils to look up annotation attributes for @DirtiesContext. Issue: SPR-11038
-
- 28 10月, 2013 1 次提交
-
-
由 Sam Brannen 提交于
Spring 3.0 already allows component stereotypes to be used in a meta-annotation fashion, for example by creating a custom @TransactionalService stereotype annotation which combines @Transactional and @Service in a single, reusable, application-specific annotation. However, the Spring TestContext Framework (TCF) currently does not provide any support for test-related annotations to be used as meta-annotations. This commit overhauls the TCF with regard to how annotations are retrieved and adds explicit support for the following annotations to be used as meta-annotations in conjunction with the TCF. - @ContextConfiguration - @ContextHierarchy - @ActiveProfiles - @DirtiesContext - @IfProfileValue - @ProfileValueSourceConfiguration - @BeforeTransaction - @AfterTransaction - @TransactionConfiguration - @Rollback - @TestExecutionListeners - @Repeat - @Timed - @WebAppConfiguration Note that meta-annotation support for @Transactional was already available prior to this commit. The following is a summary of the major changes included in this commit. - Now using AnnotationUtils.getAnnotation() instead of Class.getAnnotation() where appropriate in the TestContext Framework. - Now using AnnotationUtils.findAnnotation() instead of Class.isAnnotationPresent() where appropriate in the TestContext Framework. - Introduced findAnnotationPrefersInteracesOverLocalMetaAnnotations() in AnnotationUtilsTests in order to verify the status quo. - AnnotationUtils.findAnnotationDeclaringClass() and AnnotationUtils.findAnnotationDeclaringClassForTypes() now support meta annotations. - Introduced MetaAnnotationUtils and AnnotationDescriptor in the spring-test module. - Introduced UntypedAnnotationDescriptor in MetaAnnotationUtils. - Introduced findAnnotationDescriptorForTypes() in MetaAnnotationUtils. - ContextLoaderUtils now uses MetaAnnotationUtils for looking up @ActiveProfiles as a potential meta-annotation. - TestContextManager now uses MetaAnnotationUtils for looking up @TestExecutionListeners as a potential meta-annotation. - DirtiesContextTestExecutionListener now uses AnnotationUtils for looking up @DirtiesContext as a potential meta-annotation. - Introduced DirtiesContextTestExecutionListenerTests. - ProfileValueUtils now uses AnnotationUtils for looking up @IfProfileValue and @ProfileValueSourceConfiguration as potential meta-annotations. - @BeforeTransaction and @AfterTransaction now support ANNOTATION_TYPE as a target, allowing them to be used as meta-annotations. - TransactionalTestExecutionListener now uses AnnotationUtils for looking up @BeforeTransaction, @AfterTransaction, @Rollback, and @TransactionConfiguration as potential meta-annotations. - Introduced TransactionalTestExecutionListenerTests. - @Repeat and @Timed now support ANNOTATION_TYPE as a target, allowing them to be used as meta-annotations. - SpringJUnit4ClassRunner now uses AnnotationUtils for looking up @Repeat and @Timed as potential meta-annotations. - Moved all remaining logic for building the MergedContextConfiguration from the DefaultTestContext constructor to ContextLoaderUtils.buildMergedContextConfiguration(). - Verified meta-annotation support for @WebAppConfiguration and @ContextConfiguration. Issue: SPR-7827
-
- 14 5月, 2013 1 次提交
-
-
由 Rob Winch 提交于
Issue: SPR-10130
-
- 07 5月, 2013 1 次提交
-
-
由 Sam Brannen 提交于
This commit removes the use of @SuppressWarnings("deprecation") for code in the spring-test module that no longer references deprecated code. Issue: SPR-10499
-
- 28 4月, 2013 1 次提交
-
-
由 Sam Brannen 提交于
This commit deletes the deprecated @ExpectedException and @NotTransactional annotations, supporting code, and related Javadoc and reference documentation. Issue: SPR-10499
-
- 02 1月, 2013 1 次提交
-
-
由 Chris Beams 提交于
This reverts commit 45fa5082, reversing changes made to a312d900.
-
- 29 12月, 2012 2 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-10130
-
由 Chris Beams 提交于
Issue: SPR-10128
-
- 13 12月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
In particular, avoiding synchronized Sets and Maps wherever possible (preferring a ConcurrentHashMap even instead of a synchronized Set) and specifying appropriate ConcurrentHashMap initial capacities (even if we end up choosing 16).
-
- 04 12月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
This commit fixes recently introduced formatting errors in the Javadoc of TransactionalTestExecutionListener.
-
- 28 7月, 2012 2 次提交
-
-
由 Sam Brannen 提交于
Currently the Spring TestContext Framework looks up a PlatformTransactionManager bean named "transactionManager". The exact name of the bean can be overridden via @TransactionConfiguration or @Transactional; however, the bean will always be looked up 'by name'. The TransactionManagementConfigurer interface that was introduced in Spring 3.1 provides a programmatic approach to specifying the PlatformTransactionManager bean to be used for annotation-driven transaction management, and that bean is not required to be named "transactionManager". However, as of Spring 3.1.2, using the TransactionManagementConfigurer on a @Configuration class has no effect on how the TestContext framework looks up the transaction manager. Consequently, if an explicit name or qualifier has not been specified, the bean must be named "transactionManager" in order for a transactional integration test to work. This commit addresses this issue by refactoring the TransactionalTestExecutionListener so that it looks up and delegates to a single TransactionManagementConfigurer as part of the algorithm for determining the transaction manager. Issue: SPR-9604
-
由 Sam Brannen 提交于
TransactionalTestExecutionListener currently requires that the PlatformTransactionManager bean be named "transactionManager" by default. Otherwise, the bean name can only be overridden via the transactionManager attribute of @TransactionConfiguration or the value attribute of @Transactional. However, if there is only a single PlatformTransactionManager in the test's ApplicationContext, then the requirement to specify the exact name of that bean (or to name it exactly "transactionManager") is often superfluous. This commit addresses this issue by refactoring the TransactionalTestExecutionListener so that it is comparable to the algorithm for determining the transaction manager used in TransactionAspectSupport for "production" code. Specifically, the TTEL now uses the following algorithm to retrieve the transaction manager. - look up by type and qualifier from @Transactional - else, look up by type and explicit name from @TransactionConfiguration - else, look up single bean by type - else, look up by type and default name from @TransactionConfiguration Issue: SPR-9645
-
- 26 5月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Commit 096693c4 refactored and deprecated TransactionAspectUtils, moving its #qualifiedBeanOfType and related methods into BeanFactoryUtils. This created a package cycle between beans.factory and beans.factory.annotation due to use of the beans.factory.annotation.Qualifier annotation in these methods. This commit breaks the package cycle by introducing beans.factory.annotation.BeanFactoryAnnotationUtils and moving these @Qualifier-related methods to it. It is intentionally similar in name and style to the familiar BeanFactoryUtils class for purposes of discoverability. There are no backward-compatibilty concerns associated with this change as the cycle was introduced, caught and now fixed before a release. Issue: SPR-6847
-
- 20 5月, 2012 1 次提交
-
-
由 Chris Beams 提交于
TransactionAspectUtils contains a number of methods useful in retrieving a bean by type+qualifier. These methods are functionally general-purpose save for the hard coding of PlatformTransactionManager class literals throughout. This commit generifies these methods and moves them into BeanFactoryUtils primarily in anticipation of their use by async method execution interceptors and aspects when performing lookups for qualified executor beans e.g. via @Async("qualifier"). The public API of TransactionAspectUtils remains backward compatible; all methods within have been deprecated, and all calls to those methods throughout the framework refactored to use the new BeanFactoryUtils variants instead.
-
- 31 1月, 2012 1 次提交
-
-
由 Chris Beams 提交于
This renaming more intuitively expresses the relationship between subprojects and the JAR artifacts they produce. Tracking history across these renames is possible, but it requires use of the --follow flag to `git log`, for example $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history up until the renaming event, where $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history for all changes to the file, before and after the renaming. See http://chrisbeams.com/git-diff-across-renamed-directories
-
- 10 10月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
-
- 09 2月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
-
- 13 3月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 21 7月, 2009 1 次提交
-
-
由 Sam Brannen 提交于
[SPR-5315][SPR-5699] Reverted changes to TransactionalTestExecutionListener: transactions are no longer automatically flushed before rolling back.
-
- 19 5月, 2009 1 次提交
-
-
由 Sam Brannen 提交于
-
- 19 2月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
added "flush()" method to TransactionStatus and TransactionSynchronization interfaces; test context manager automatically flushes transactions before rolling back; general polishing of transaction management code
-
- 27 10月, 2008 1 次提交
-
-
由 Arjen Poutsma 提交于
-