- 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 7月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
Currently the getNamedDispatcher(String) method of MockServletContext always returns null. This poses a problem in certain testing scenarios since one would always expect at least a default Servlet to be present. This is specifically important for web application tests that involve the DefaultServletHttpRequestHandler which attempts to forward to the default Servlet after retrieving it by name. Furthermore, there is no way to register a named RequestDispatcher with the MockServletContext. This commit addresses these issues by introducing the following in MockServletContext. - a new defaultServletName property for configuring the name of the default Servlet, which defaults to "default" - named RequestDispatchers can be registered and unregistered - a MockRequestDispatcher is registered for the "default" Servlet automatically in the constructor - when the defaultServletName property is set to a new value the the current default RequestDispatcher is unregistered and replaced with a MockRequestDispatcher for the new defaultServletName Issue: SPR-9587
-
- 25 7月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
-
- 17 7月, 2012 1 次提交
-
-
由 Rob Winch 提交于
Previously MockHttpServletRequest#sendRedirect did not set the HTTP status or the Location header. This does not conform to the HttpServletRequest interface. MockHttpServletRequest will now: - Set the HTTP status to 302 on sendRedirect - Set the Location header on sendRedirect - Ensure the Location header and getRedirectedUrl are kept in synch Issue: SPR-9594
-
- 19 6月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
Fixed outdated Javadoc regarding support for 'annotated classes' in the TestContext Framework.
-
- 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.
-
- 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 2 次提交
-
-
由 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
-
由 Stevo Slavic 提交于
Before this change javadoc in two classes had non-UTF-8 encoded characters. This caused building Spring API to fail in Java 1.7. Commit fixes this by replacing wrongly encoded characters with their UTF-8 equivalents. Issue: SPR-9097
-
- 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
-