- 08 3月, 2016 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Phillip Webb 提交于
Update @WebAppConfiguration so that it no longer directly specifies a TestContextBootstrapper. This allows third parties to use the annotation in combination with their own bootstrapper. BootstrapUtils now provides the detection logic for when WebTestContextBootstrapper should be used. Issue: SPR-13991
-
- 03 3月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
This commit changes the visibility of the getTestContext() method in TestContextManager from 'protected' to 'public' in order to support test method injection in JUnit 5 and similar use cases. Issue: SPR-14011
-
- 29 2月, 2016 4 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, the TransactionalTestExecutionListener required @Transactional test methods to be public; however, neither TestNG nor JUnit 5 require that @test methods are public. Consequently, non-public transactional test methods silently run *without* a transaction. This commit removes the 'public' restriction on transactional test methods by setting the 'publicMethodsOnly' flag in AnnotationTransactionAttributeSource to false. Issue: SPR-14000
-
由 Sam Brannen 提交于
-
由 Juergen Hoeller 提交于
-
由 Sam Brannen 提交于
In order to align with the relaxed programming models of TestNG and the upcoming JUnit 5 (with regard to method visibility), this commit removes the requirement that @BeforeTransaction and @AfterTransaction methods must be 'public'. Issue: SPR-13997
-
- 28 2月, 2016 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
This commit introduces a SpringRunner extension of SpringJUnit4ClassRunner that is intended to be used as an 'alias' for SpringJUnit4ClassRunner, primarily in order to simplify configuration of JUnit 4 based integration tests. Developers can use this alias as follows: @RunWith(SpringRunner.class) public class MySpringIntegrationTests { ... } Issue: SPR-13954
-
- 25 2月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 23 2月, 2016 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 19 2月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13961
-
- 17 2月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13951
-
- 04 2月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, the transaction manager and data source look-up algorithms in the Spring TestContext Framework were not capable of retrieving 'primary' beans of those types, even though 'primary' beans are supported in production as well as for injecting dependencies into test instances. Specifically, if there was more than one transaction manager or data source bean and one of them was flagged as 'primary', the retrieveTransactionManager() and retrieveDataSource() methods in TestContextTransactionUtils would simply return null for such beans. This commit updates TestContextTransactionUtils by adding support for looking up primary transaction managers and data sources. Issue: SPR-13891
-
- 03 2月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, a @Transactional integration test would silently be executed without a transaction if the transaction manager could not be retrieved from the application context -- for example, it no such bean was defined or if multiple beans were present but none satisfied the qualifier. This commit addresses this issue by throwing an IllegalStateException if the PlatformTransactionManager cannot be retrieved for a @Transactional test. Issue: SPR-13895
-
- 20 12月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Issue: SPR-13275
-
- 18 12月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 08 12月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 29 9月, 2015 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Sam Brannen 提交于
SpringJUnit4ClassRunner, SpringClassRule, and SpringMethodRule now throw an IllegalStateException with a meaningful message if JUnit 4.9 is not present in the classpath (specifically if org.junit.runners.model.MultipleFailureException cannot be loaded). Issue: SPR-13521
-
- 20 8月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 29 7月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
SPR-11512 introduced support for annotation attribute aliases via @AliasFor, requiring the explicit declaration of the 'attribute' attribute. However, for aliases within an annotation, this explicit declaration is unnecessary. This commit improves the readability of alias pairs declared within an annotation by introducing a 'value' attribute in @AliasFor that is an alias for the existing 'attribute' attribute. This allows annotations such as @ContextConfiguration from the spring-test module to declare aliases as follows. public @interface ContextConfiguration { @AliasFor("locations") String[] value() default {}; @AliasFor("value") String[] locations() default {}; // ... } Issue: SPR-13289
-
- 26 7月, 2015 3 次提交
-
-
由 Sam Brannen 提交于
Since @TransactionConfiguration is now deprecated, this commit also deprecates TransactionConfigurationAttributes with the intention of completely removing TransactionConfigurationAttributes once @TransactionConfiguration has been removed. Issue: SPR-13277
-
由 Sam Brannen 提交于
Due to common usage of @Rollback(false), this commit introduces a new @Commit annotation that more clearly conveys the intent of the code while retaining the run-time semantics. @Commit is in fact meta-annotated with @Rollback(false). Issue: SPR-13279
-
由 Sam Brannen 提交于
Since Spring Framework 2.5, @Rollback has been supported on test methods, with class-level rollback settings configured via @TransactionConfiguration; however, allowing @Rollback to be declared on test classes with method-level declarations overriding class-level declarations would prove more intuitive than having to declare both @TransactionConfiguration and @Rollback. Furthermore, the transactionManager flag in @TransactionConfiguration was made superfluous many years ago with the introduction of support for a qualifier in @Transactional. This commit enables @Rollback to be declared at the class level for default rollback semantics within test class hierarchies and deprecates @TransactionConfiguration in favor of @Rollback and @Transactional qualifiers. Issue: SPR-13276, SPR-13277
-
- 25 7月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 24 7月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 21 7月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, the Spring MVC Test Framework always created a new MockHttpServletRequest, disregarding any mock request already present in Spring Web's RequestContextHolder -- for example, one created by the ServletTestExecutionListener in the Spring TestContext Framework (TCF). This commit modifies MockHttpServletRequestBuilder so that it reuses a mock request created by the TCF. However, MockMultipartHttpServletRequestBuilder continues to always create a new MockMultipartHttpServletRequest since a MockHttpServletRequest created by the TCF is not directly compatible with a MockMultipartHttpServletRequest. Furthermore, in order to avoid unforeseen side effects, MockHttpServletRequestBuilder will always create a new MockHttpServletRequest if a mock request is present in the RequestContextHolder but not created by the TCF. Issue: SPR-13211
-
- 02 7月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
SPR-12429 introduced various `BEFORE_*` modes in `@DirtiesContext`. To support these new modes, `DirtiesContextTestExecutionListener` (DCTEL) was updated to support both `BEFORE_*` and `AFTER_*` modes. However, there is a problem with having DCTEL support `BEFORE_*` modes since it is typically configured to execute after the `DependencyInjectionTestExecutionListener` (DITEL), and this leads to several undesired side effects: - The test's `ApplicationContext` is closed by DCTEL *after* dependencies have been injected into the test instance. - Injected dependencies may therefore attempt to interact with an `ApplicationContext` that is no longer _active_. - If a test has its `ApplicationContext` injected as a dependency, interaction with the context will likely fail since the context has been closed. - Any `TestExecutionListeners` registered after DCTEL will get a _new_ `ApplicationContext` if they invoke `getApplicationContext()` on the `TestContext`. This commit fixes these issues by introducing a new `DirtiesContextBeforeModesTestExecutionListener` (DCBMTEL) that is registered by default before DITEL. The previous support for `BEFORE_*` modes has been moved from DCTEL to DCBMTEL. In addition, an `AbstractDirtiesContextTestExecutionListener` has been extracted from DCTEL in order to avoid code duplication. Issue: SPR-13180
-
- 24 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, it was only possible to declare SQL statements via @Sql within external script resources (i.e., classpath or file system resources); however, many developers have inquired about the ability to inline SQL statements with @Sql analogous to the support for inlined properties in @TestPropertySource. This commit introduces support for declaring _inlined SQL statements_ in `@Sql` via a new `statements` attribute. Inlined statements are executed after statements in scripts. Issue: SPR-13159
-
- 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
-
- 20 6月, 2015 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Prior to this commit, the implementation of getRepeatableAnnotation() in Spring's AnnotationUtils complied neither with the contract of getAnnotationsByType() nor with the contract of getDeclaredAnnotationsByType() as defined in AnnotatedElement in Java 8. Specifically, unexpected results can be encountered when using Spring's support for @Repeatable annotations: either annotations show up in the returned set in the wrong order, or annotations are returned in the set that should not even be found based on the semantics of @Repeatable. This commit remedies this problem by deprecating the existing getRepeatableAnnotation() methods and replacing them with new getRepeatableAnnotations() and getDeclaredRepeatableAnnotations() methods that comply with the contracts of Java's getAnnotationsByType() and getDeclaredAnnotationsByType(), respectively. Issue: SPR-13068
-
- 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
-
- 15 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Ever since @ActiveProfiles was introduced, the declared active profiles for integration tests have been sorted in order to support unique cache key generation; however, there are use cases for which the original ordering should be retained. For example, Spring Boot's ConfigFileApplicationListener loads configuration files for active profiles in the order returned by Environment.getActiveProfiles(), with the assumption that the ordering matches the order in which the developer declared the active profiles. This commit maintains the uniqueness of active profiles declared via @ActiveProfiles but no longer sorts them. Issue: SPR-12492
-
- 14 6月, 2015 2 次提交
-
-
由 Sam Brannen 提交于
-
由 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
-
- 22 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
This commit introduces first-class support for aliases for annotation attributes. Specifically, this commit introduces a new @AliasFor annotation that can be used to declare a pair of aliased attributes within a single annotation or an alias from an attribute in a custom composed annotation to an attribute in a meta-annotation. To support @AliasFor within annotation instances, AnnotationUtils has been overhauled to "synthesize" any annotations returned by "get" and "find" searches. A SynthesizedAnnotation is an annotation that is wrapped in a JDK dynamic proxy which provides run-time support for @AliasFor semantics. SynthesizedAnnotationInvocationHandler is the actual handler behind the proxy. In addition, the contract for @AliasFor is fully validated, and an AnnotationConfigurationException is thrown in case invalid configuration is detected. For example, @ContextConfiguration from the spring-test module is now declared as follows: public @interface ContextConfiguration { @AliasFor(attribute = "locations") String[] value() default {}; @AliasFor(attribute = "value") String[] locations() default {}; // ... } The following annotations and their related support classes have been modified to use @AliasFor. - @ManagedResource - @ContextConfiguration - @ActiveProfiles - @TestExecutionListeners - @TestPropertySource - @Sql - @ControllerAdvice - @RequestMapping Similarly, support for AnnotationAttributes has been reworked to support @AliasFor as well. This allows for fine-grained control over exactly which attributes are overridden within an annotation hierarchy. In fact, it is now possible to declare an alias for the 'value' attribute of a meta-annotation. For example, given the revised declaration of @ContextConfiguration above, one can now develop a composed annotation with a custom attribute override as follows. @ContextConfiguration public @interface MyTestConfig { @AliasFor( annotation = ContextConfiguration.class, attribute = "locations" ) String[] xmlFiles(); // ... } Consequently, the following are functionally equivalent. - @MyTestConfig(xmlFiles = "test.xml") - @ContextConfiguration("test.xml") - @ContextConfiguration(locations = "test.xml"). Issue: SPR-11512, SPR-11513
-