- 25 2月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 17 2月, 2015 2 次提交
-
-
由 Sam Brannen 提交于
Spring Framework 4.1 introduced support for @TestPropertySource; however, the utilities used to parse inlined properties and add test property sources to the environment are currently private which prevents reuse by third-party frameworks like Spring Boot. This commit addresses this issue by making such utilities public. - TestPropertySourceUtils is now a public class. - Various utility methods in TestPropertySourceUtils have been made public. - addResourcePropertySourcesToEnvironment() has been renamed to addPropertiesFilesToEnvironment(). - extractEnvironmentProperties() has been renamed to convertInlinedPropertiesToMap(). - All public methods in TestPropertySourceUtils are now fully documented. Issue: SPR-12721
-
由 Sam Brannen 提交于
The initial implementation for adding inlined properties configured via @TestPropertySource to the context's environment did not preserve the order in which the properties were physically declared. This makes @TestPropertySource a poor testing facility for mimicking the production environment's configuration if the property source mechanism used in production preserves ordering of property names -- which is the case for YAML-based property sources used in Spring Boot, Spring Yarn, etc. This commit addresses this issue by ensuring that the ordering of inlined properties declared via @TestPropertySource is preserved. Specifically, the original functionality has been refactored. extracted from AbstractContextLoader, and moved to TestPropertySourceUtils where it may later be made public for general purpose use in other frameworks. Issue: SPR-12710
-
- 21 10月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 14 8月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
Spring Framework 3.1 introduced an Environment abstraction with support for hierarchical PropertySources that can be configured programmatically as well as declaratively via the @PropertySource annotation. However, prior to this commit, there was no way to declaratively configure PropertySources in integration tests in the Spring TestContext Framework (TCF). This commit introduces declarative support for PropertySources in the TCF via a new class-level @TestPropertySource annotation. This annotation provides two options for declaring test property sources: - The 'locations' attribute allows developers to declare external resource locations for test properties files. - The 'properties' attribute allows developers to declare inlined properties in the form of key-value pairs. Test properties files are added to the Environment before all other property sources and can therefore override system and application property sources. Similarly, inlined properties are added to the Environment before all other property sources and can therefore override system property sources, application property sources, and test properties files. Specifically, this commit introduces the following major changes: - Introduced @TestPropertySource annotation along with internal TestPropertySourceAttributes, MergedTestPropertySources, and TestPropertySourceUtils for working with test property sources within the TCF. - All TestContextBootstrappers have been modified to support the merged property resource locations and inlined properties from @TestPropertySource. - MergedContextConfiguration (and consequently the context caching key) is now additionally based on the merged property resource locations and inlined properties from @TestPropertySource. The same applies to WebMergedContextConfiguration. - AbstractContextLoader's prepareContext() method now adds PropertySources for all resource locations and inlined properties from the supplied MergedContextConfiguration to the Environment of the supplied ApplicationContext. All subclasses of AbstractGenericContextLoader and AbstractGenericWebContextLoader therefore automatically provide support for @TestPropertySource. Issue: SPR-12051
-
- 24 7月, 2014 1 次提交
-
-
由 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
-
- 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
-
- 16 1月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 20 11月, 2013 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 14 5月, 2013 1 次提交
-
-
由 Rob Winch 提交于
Issue: SPR-10130
-
- 23 1月, 2013 1 次提交
-
-
由 Phillip Webb 提交于
Fix unnecessary HTML escaping from {@code} Javadoc.
-
- 02 1月, 2013 1 次提交
-
-
由 Chris Beams 提交于
This reverts commit 45fa5082, reversing changes made to a312d900.
-
- 29 12月, 2012 3 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-10130
-
由 Chris Beams 提交于
Issue: SPR-10128
-
由 Phillip Webb 提交于
find . -type f -name "*.java" -or -name "*.aj" | \ xargs perl -p -i -e "s/[ \t]*$//g" {} \; Issue: SPR-10127
-
- 08 10月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, the Spring TestContext Framework only supported loading an ApplicationContext in integration tests from either XML or Java Properties files (since Spring 2.5), and Spring 3.1 introduced support for loading an ApplicationContext in integration tests from annotated classes (e.g., @Configuration classes). All of the ContextLoader implementations used to provide this support load a GenericApplicationContext. However, a GenericApplicationContext is not suitable for testing a web application since a web application relies on an implementation of WebApplicationContext (WAC). This commit makes it possible to integration test Spring-powered web applications by adding the following functionality to the Spring TestContext Framework. - Introduced AbstractGenericWebContextLoader and two concrete subclasses: - XmlWebContextLoader - AnnotationConfigWebContextLoader - Pulled up prepareContext(context, mergedConfig) from AbstractGenericContextLoader into AbstractContextLoader to allow it to be shared across web and non-web context loaders. - Introduced AnnotationConfigContextLoaderUtils and refactored AnnotationConfigContextLoader accordingly. These utils are also used by AnnotationConfigWebContextLoader. - Introduced a new @WebAppConfiguration annotation to denote that the ApplicationContext loaded for a test should be a WAC and to configure the base resource path for the root directory of a web application. - Introduced WebMergedContextConfiguration which extends MergedContextConfiguration with support for a baseResourcePath for the root directory of a web application. - ContextLoaderUtils.buildMergedContextConfiguration() now builds a WebMergedContextConfiguration instead of a standard MergedContextConfiguration if @WebAppConfiguration is present on the test class. - Introduced a configureWebResources() method in AbstractGenericWebContextLoader that is responsible for creating a MockServletContext with a proper ResourceLoader for the resourceBasePath configured in the WebMergedContextConfiguration. The resulting mock ServletContext is set in the WAC, and the WAC is stored as the Root WAC in the ServletContext. - Introduced a WebTestExecutionListener that sets up default thread local state via RequestContextHolder before each test method by using the MockServletContext already present in the WAC and by creating a MockHttpServletRequest, MockHttpServletResponse, and ServletWebRequest that is set in the RequestContextHolder. WTEL also ensures that the MockHttpServletResponse and ServletWebRequest can be injected into the test instance (e.g., via @Autowired) and cleans up thread locals after each test method. - WebTestExecutionListener is configured as a default TestExecutionListener before DependencyInjectionTestExecutionListener - Extracted AbstractDelegatingSmartContextLoader from DelegatingSmartContextLoader and introduced a new WebDelegatingSmartContextLoader. - ContextLoaderUtils now selects the default delegating ContextLoader class name based on the presence of @WebAppConfiguration on the test class. - Tests in the spring-test-mvc module no longer use a custom ContextLoader to load a WebApplicationContext. Instead, they now rely on new core functionality provided in this commit. Issue: SPR-5243
-
- 18 5月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
Updated all Javadoc in the Spring TestContext Framework (TCF) to explain and refer to 'annotated classes' instead of 'configuration classes'. Specifically, @ContextConfiguration now explicitly defines what is meant by 'annotated classes', and various other classes now refer to this definition. Otherwise, the term 'configuration class' has simply been replaced with 'annotated class'. Also deleted cross references to deprecated JUnit 3.8 classes and formatted Javadoc in general for greater readability. Issue: SPR-9401
-
- 30 4月, 2012 1 次提交
-
-
由 Stevo Slavic 提交于
Before this change there were numerous javadoc warnings being reported while building Spring framework API. This commit resolves most of the javadoc warnings, reducing the total number from 265 to 103. Issue: SPR-9113
-
- 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
-
- 30 9月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
[SPR-8240] polishing the "Context management and caching" section of the reference manual and related Javadoc.
-
- 21 8月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
-
- 13 8月, 2011 2 次提交
-
-
由 Sam Brannen 提交于
[SPR-8386][SPR-8387] Refined logging regarding detection of default resource locations and default configuration classes.
-
由 Sam Brannen 提交于
- Removed generatesDefaults() and supports() from the SmartContextLoader SPI and modified the DelegatingSmartContextLoader algorithm accordingly. - DelegatingSmartContextLoader no longer operates on a list of candidate loaders but rather on explicit instances of GenericXmlContextLoader and AnnotationConfigContextLoader. - Updated Javadoc regarding DelegatingSmartContextLoader as the new default loader. - Updated and polished Javadoc regarding changes in 3.1. - Now enforcing @ContextConfiguration's restriction on declaring locations or classes but not both.
-
- 21 7月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
-
- 16 7月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
-
- 27 6月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
[SPR-8387] Introduced supports(MergedContextConfiguration) method in the SmartContextLoader SPI; updated existing loaders accordingly; and fleshed out implementation of and tests for the new DelegatingSmartContextLoader.
-
- 26 6月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
-
- 21 6月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
[SPR-8386] AbstractContextLoader now adheres to the SmartContextLoader contract by verifying the existence of generated default resource locations.
-
- 20 6月, 2011 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
- 19 6月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
[SPR-8386] Polishing SmartContextLoader SPI; AnnotationConfigContextLoader now only considers static inner classes annotated with @Configuration as configuration classes.
-
- 18 6月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
- introduced processContextConfigurationAttributes() method in SmartContextLoader SPI - refactored AnnotationConfigContextLoader, AbstractContextLoader, AbstractGenericContextLoader, ContextLoaderUtils, and TestContext implementations to take advantage of the SmartContextLoader SPI, MergedContextConfiguration, and ContextConfigurationAttributes - deleted ResourceTypeAwareContextLoader - deleted ContextLoaderUtils.LocationsResolver and implementations - moved context key generation from TestContext to MergedContextConfiguration
-
- 03 6月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
[SPR-7960][SPR-8386] Supporting declarative configuration of bean definition profiles in the TestContext framework: - TextContext now works with MergedContextConfiguration instead of locations and loader - TextContext now builds context caching key from MergedContextConfiguration - Test context caching is now based on locations, classes, active profiles, and context loader - TextContext now delegates to SmartContextLoader or ContextLoader as appropriate - AbstractContextLoader now implements SmartContextLoader - AbstractGenericContextLoader now sets active profiles in the GenericApplicationContext - Introduced integration tests for profile support in the TCF for both XML and annotation config
-
- 09 4月, 2011 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
- 04 4月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
[SPR-6184] Introduced ResourceTypeAwareContextLoader interface and removed dependency on AnnotationConfigContextLoader in TestContext.
-
- 09 12月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 27 10月, 2008 1 次提交
-
-
由 Arjen Poutsma 提交于
-