- 29 12月, 2012 1 次提交
-
-
由 Phillip Webb 提交于
find . -type f -name "*.java" -or -name "*.aj" | \ xargs perl -p -i -e "s/[ \t]*$//g" {} \; Issue: SPR-10127
-
- 12 12月, 2012 1 次提交
-
-
由 Chris Beams 提交于
- Support external Javadoc links using Gradle's javadoc.options.links - Fix all other Javadoc warnings, such as typos, references to non-existent (or no longer existent) types and members, etc, including changes related to the Quartz 2.0 upgrade (SPR-8275) and adding the HTTP PATCH method (SPR-7985). - Suppress all output for project-level `javadoc` tasks in order to hide false-negative warnings about cross-module @see and @link references (e.g. spring-core having a @see reference to spring-web). Use the `--info` (-i) flag to gradle at any time to see project-level javadoc warnings without running the entire `api` task. e.g. `gradle :spring-core:javadoc -i` - Favor root project level `api` task for detection of legitimate Javadoc warnings. There are now zero Javadoc warnings across the entirety of spring-framework. Goal: keep it that way. - Remove all @link and @see references to types and members that exist only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+ respectively. This is necessary because only one version of each of these dependencies can be present on the global `api` javadoc task's classpath. To that end, the `api` task classpath has now been customized to ensure that the Servlet 3 API and Hibernate Core 4 jars have precedence. - SPR-8896 replaced our dependency on aspectjrt with a dependency on aspectjweaver, which is fine from a POM point of view, but causes a spurious warning to be emitted from the ant iajc task that it "cannot find aspectjrt on the classpath" - even though aspectjweaver is perfectly sufficient. In the name of keeping the console quiet, a new `rt` configuration has been added, and aspectjrt added as a dependency to it. In turn, configurations.rt.asPath is appended to the iajc classpath during both compileJava and compileTestJava for spring-aspects. Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896
-
- 11 12月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
This commit adds Javadoc documentation for the WebApplicationContext testing support that was recently introduced in the Spring TestContext Framework. Issue: SPR-9864
-
- 04 12月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
This commit relocates recently introduced web artifacts in the TestContext framework to the ~.test.context.web package and renames some classes for consistency with the existing code base. - introduced package-info.java in the web package. - ServletTestExecutionListener now extends AbstractTestExecutionListener instead of implementing TestExecutionListener. - relocated AbstractGenericWebContextLoader, AnnotationConfigWebContextLoader, XmlWebContextLoader, and WebDelegatingSmartContextLoader to the web package. - renamed XmlWebContextLoader to GenericXmlWebContextLoader for consistency with GenericXmlContextLoader. - changed the visibility of AbstractDelegatingSmartContextLoader and AnnotationConfigContextLoaderUtils to public. Issue: SPR-10067
-
- 14 10月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
Issue: SPR-9864
-
- 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
-
- 20 8月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
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
-
- 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
-