1. 08 7月, 2016 1 次提交
  2. 05 4月, 2016 1 次提交
  3. 18 12月, 2015 1 次提交
  4. 09 12月, 2014 1 次提交
  5. 15 8月, 2014 1 次提交
    • S
      Support automatic discovery of default TELs · e6d16148
      Sam Brannen 提交于
      Prior to this commit, there was no declarative mechanism for a custom
      TestExecutionListener to be registered as a default
      TestExecutionListener.
      
      This commit introduces support for discovering default
      TestExecutionListener implementations via the SpringFactoriesLoader
      mechanism. Specifically, the spring-test module declares all core
      default TestExecutionListeners under the
      org.springframework.test.context.TestExecutionListener key in its
      META-INF/spring.factories properties file, and third-party frameworks
      and developers can contribute to the list of default
      TestExecutionListeners in the same manner.
      
       - AbstractTestContextBootstrapper uses the SpringFactoriesLoader to
         look up the class names of all registered default
         TestExecutionListeners and sorts the instantiated listeners using
         AnnotationAwareOrderComparator.
      
       - DefaultTestContextBootstrapper and WebTestContextBootstrapper now
         rely on the SpringFactoriesLoader mechanism for finding default
         TestExecutionListeners instead of hard coding fully qualified class
         names.
      
       - To ensure that default TestExecutionListeners are registered in the
         correct order, each can implement Ordered or declare @order.
      
       - AbstractTestExecutionListener and all default TestExecutionListeners
         provided by Spring now implement Ordered with appropriate values.
      
       - Introduced "copy constructors" in MergedContextConfiguration and
         WebMergedContextConfiguration
      
       - SpringFactoriesLoader now uses AnnotationAwareOrderComparator
         instead of OrderComparator.
      
      Issue: SPR-11466
      e6d16148
  6. 19 7月, 2014 1 次提交
  7. 07 3月, 2013 1 次提交
    • S
      Provide support for context hierarchies in the TCF · 98074e77
      Sam Brannen 提交于
      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
      98074e77
  8. 29 12月, 2012 3 次提交
  9. 31 1月, 2012 1 次提交
    • C
      Rename modules {org.springframework.*=>spring-*} · 02a4473c
      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
      02a4473c
  10. 06 7月, 2009 2 次提交
  11. 05 7月, 2009 1 次提交
  12. 27 10月, 2008 1 次提交