spring-framework

0 Tags

126 MiB

Author	SHA1	Message	Date
Sam Brannen	1f017c4acb	Support classes AND locations in @ContextConfiguration Prior to this commit, the Spring TestContext Framework did not support the declaration of both 'locations' and 'classes' within @ContextConfiguration at the same time. This commit addresses this in the following manner: - ContextConfigurationAttributes no longer throws an IllegalArgumentException if both 'locations' and 'classes' are supplied to its constructor. - Concrete SmartContextLoader implementations now validate the supplied MergedContextConfiguration before attempting to load the ApplicationContext. See validateMergedContextConfiguration(). - Introduced tests for hybrid context loaders like the one used in Spring Boot. See HybridContextLoaderTests. - Updated the Testing chapter of the reference manual so that it no longer states that locations and classes cannot be used simultaneously, mentioning Spring Boot as well. - The Javadoc for @ContextConfiguration has been updated accordingly. - Added hasLocations(), hasClasses(), and hasResources() convenience methods to MergedContextConfiguration. Issue: SPR-11634	11 years ago
Sam Brannen	98074e7762	Provide support for context hierarchies in the TCF Prior to this commit the Spring TestContext Framework supported creating only flat, non-hierarchical contexts. There was no easy way to create contexts with parent-child relationships. This commit addresses this issue by introducing a new @ContextHierarchy annotation that can be used in conjunction with @ContextConfiguration for declaring hierarchies of application contexts, either within a single test class or within a test class hierarchy. In addition, @DirtiesContext now supports a new 'hierarchyMode' attribute for controlling context cache clearing for context hierarchies. - Introduced a new @ContextHierarchy annotation. - Introduced 'name' attribute in @ContextConfiguration. - Introduced 'name' property in ContextConfigurationAttributes. - TestContext is now aware of @ContextHierarchy in addition to @ContextConfiguration. - Introduced findAnnotationDeclaringClassForTypes() in AnnotationUtils. - Introduced resolveContextHierarchyAttributes() in ContextLoaderUtils. - Introduced buildContextHierarchyMap() in ContextLoaderUtils. - @ContextConfiguration and @ContextHierarchy may not be used as top-level, class-level annotations simultaneously. - Introduced reference to the parent configuration in MergedContextConfiguration and WebMergedContextConfiguration. - Introduced overloaded buildMergedContextConfiguration() methods in ContextLoaderUtils in order to handle context hierarchies separately from conventional, non-hierarchical contexts. - Introduced hashCode() and equals() in ContextConfigurationAttributes. - ContextLoaderUtils ensures uniqueness of @ContextConfiguration elements within a single @ContextHierarchy declaration. - Introduced CacheAwareContextLoaderDelegate that can be used for loading contexts with transparent support for interacting with the context cache -- for example, for retrieving the parent application context in a context hierarchy. - TestContext now delegates to CacheAwareContextLoaderDelegate for loading contexts. - Introduced getParentApplicationContext() in MergedContextConfiguration - The loadContext(MergedContextConfiguration) methods in AbstractGenericContextLoader and AbstractGenericWebContextLoader now set the parent context as appropriate. - Introduced 'hierarchyMode' attribute in @DirtiesContext with a corresponding HierarchyMode enum that defines EXHAUSTIVE and CURRENT_LEVEL cache removal modes. - ContextCache now internally tracks the relationships between contexts that make up a context hierarchy. Furthermore, when a context is removed, if it is part of a context hierarchy all corresponding contexts will be removed from the cache according to the supplied HierarchyMode. - AbstractGenericWebContextLoader will set a loaded context as the ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE in the MockServletContext when context hierarchies are used if the context has no parent or if the context has a parent that is not a WAC. - Where appropriate, updated Javadoc to refer to the ServletTestExecutionListener, which was introduced in 3.2.0. - Updated Javadoc to avoid and/or suppress warnings in spring-test. - Suppressed remaining warnings in code in spring-test. Issue: SPR-5613, SPR-9863	12 years ago
Sam Brannen	21ebbb9c02	Support session & request scoped beans in the TCF This commit introduces RequestAndSessionScopedBeansWacTests which verifies support for request and session scoped beans in the Spring TestContext Framework (TCF). This support was actually introduced as an intentional side effect of the work performed for SPR-5243 through the addition of the new WebTestExecutionListener. Issue: SPR-4588	12 years ago
Sam Brannen	a73280ccc8	Support loading WebApplicationContexts in the TCF 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	12 years ago
Sam Brannen	1f93777bbd	Support ApplicationContextInitializers in the TCF Starting with Spring 3.1 applications can specify contextInitializerClasses via context-param and init-param in web.xml; however, there is currently no way to have such initializers invoked in integration testing scenarios without writing a custom SmartContextLoader. For comprehensive integration testing it should therefore be possible to re-use ApplicationContextInitializers in the Spring TestContext Framework as well. This commit makes this possible at the @ContextConfiguration level by allowing an array of ACI types to be specified, and the out-of-the-box SmartContextLoader implementations invoke the declared initializers at the appropriate time. - Added initializers and inheritInitializers attributes to @ContextConfiguration. - Introduced support for ApplicationContextInitializers in ContextConfigurationAttributes, MergedContextConfiguration, and ContextLoaderUtils. - MergedContextConfiguration stores context initializer classes as a Set and incorporates them into the implementations of hashCode() and equals() for proper context caching. - ApplicationContextInitializers are invoked in the new prepareContext(GenericApplicationContext, MergedContextConfiguration) method in AbstractGenericContextLoader, and ordering declared via the Ordered interface and @Order annotation is honored. - Updated DelegatingSmartContextLoader to support initializers. Specifically, a test class may optionally declare neither XML configuration files nor annotated classes and instead declare only application context initializers. In such cases, an attempt will still be made to detect defaults, but their absence will not result an an exception. - Documented support for application context initializers in Javadoc and in the testing chapter of the reference manual. Issue: SPR-9011	12 years ago
Chris Beams	02a4473c62	Rename modules {org.springframework.=>spring-} 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	13 years ago
Sam Brannen	2913964b41	[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	13 years ago
Chris Beams	4f6df87615	Fix obscure STS error Remove all bean configuration files from .springBeans to avoid cryptic STS error.	14 years ago
Chris Beams	f5768fe00b	Introduce (Annotation)SessionFactoryBuilder types Large refactoring of existing SessionFactoryBean hierarchy designed to support configuration of Hibernate SessionFactory objects within @Configuration class @Bean methods without forcing use of a FactoryBean type, which is generally discouraged due to awkwardness of programming model and lifecycle issues. Refactored and new types include: Removal of AbstractSessionFactoryBean, replacing it with SessionFactoryBeanSupport abstract base class * Introduction of SessionFactoryBuilder and AnnotationSessionFactoryBuilder types, both direct subclasses of SessionFactoryBuilderSupport. These types are intended for direct use within @Bean methods. They expose method-chainable set* methods allowing for concise and convenient use. See JavaDoc on both types for usage examples. * LocalSessionFactoryBean and AnnotationSessionFactoryBean types are now subclasses, respectively, of the Builder types above. LSFB and ASFB backward-compatibility has been maintained almost entirely. The one exception is that there is no longer a protected convertHibernateAccessException() method available in the hierarchy. This method was not likely often used anyway and has been replaced by the new (and public) setPersistenceExceptionTranslator() which accepts instances of type HibernateExceptionTranslator as introduced in SPR-8076. LSFB and ASFB setter method signatures have changed. They no longer return void in standard JavaBeans style but rather, and due to extending the Builder types above, return the 'this' reference. This posed a problem because the Spring container has to date been unable to detect and provide dependency injection against non-void returning setter methods. This limitation was due to the way that the default JavaBeans Introspector class and its getBeanInfo() method works, and prompted the introduction and intergration of ExtendedBeanInfo, already completed in SPR-8079. So have no concern if you notice this signature change - it all works. Certain deprecations have been made: * All LSFB/ASFB methods related to Hibernate's CacheProvider SPI, reflecting its deprecation in Hibernate 3.3 in favor of the new RegionFactory SPI. Note these methods have been preserved only on the FactoryBean types. The new SessionFactoryBuilder supertypes do not expose CacheProvider services at all. All protected LSFB/ASFB methods that accept a Hibernate Configuration parameter, such as newSessionFactory(Configuration), postProcessMappings(Configuration) and postProcessConfiguration(Configuation), in favor of no-arg methods with the same names. Due to the nature of the hierarchy refactoring mentioned above, the Configuration instance is always available when these methods are called, thus no need to pass it in as a parameter. In the process, our approach to automatic detection of Hibernate dialect has been improved (it was in fact broken before). Thanks to James Roper for his suggestion in SPR-7936 as to how to fix this. See HibernateSessionFactoryConfigurationTests as a starting point for understanding the new builder-style approach to SessionFactory creation. Note especially use of the SessionFactoryBuilder#doWithConfiguration method which allows for direct programmatic configuration of the Native Hibernate (Annotation)Configuration API. As a final note, AnnotationConfiguration has been deprecated in Hibernate 3.6, and great pains have been taken to ensure that users of any supported Hibernate version (3.2 -> 3.6) will never need to (a) cast from Configuration to AnnotationConfiguration or (b) experience deprecation warnings due to being forced to use the AnnotationConfiguration API. Explore the JavaDoc around the doWithConfiguration() method and HibernateConfigurationCallback type for complete details. Issue: SPR-8066, SPR-7936, SPR-8076, SPR-8098	14 years ago
Sam Brannen	b130a36af7	[SPR-7850][SPR-7851] Upgraded to JUnit 4.8.1 and TestNG 5.12.1; added changelog entries for 3.1.0.M1.	14 years ago

6 Commits (041437f3eea416bef2c5486480935cbc5c78a8c6)