1. 16 12月, 2015 1 次提交
  2. 21 10月, 2014 1 次提交
  3. 28 5月, 2014 1 次提交
    • R
      Add ResourceTransformer and CSS link implementation · 6966e895
      Rossen Stoyanchev 提交于
      This change adds a ResourceTransformer that can be invoked in a chain
      after resource resolution. The CssLinkResourceTransformer modifies a
      CSS file being served in order to update its @import and url() links
      (e.g. to images or other CSS files) to match the resource resolution
      strategy (e.g. adding MD5 content-based hashes).
      
      Issue: SPR-11800
      6966e895
  4. 26 4月, 2014 1 次提交
  5. 22 4月, 2014 1 次提交
    • S
      Polish static resource handling mechanism · 3d18cfea
      Sam Brannen 提交于
      - ResourceResolver and ResourceResolverChain now have a consistent API
        with regard to method names and terminology.
      
      - ResourceResolver and ResourceResolverChain now accept
        List<? extends Resource> instead of List<Resource> for simplified
        programmatic use.
      
      - Improved Javadoc across the package.
      
      - Formatted code to align with standards.
      
      - Removed all references to ResourceUrlPathTranslator.
      
      Issue: SPR-10933
      3d18cfea
  6. 17 4月, 2014 1 次提交
    • R
      Expand static resource handling mechanism · 6cb9a144
      Rossen Stoyanchev 提交于
      An initial commit with expanded support for static resource handling:
      
      - Add ResourceResolver strategy for resolving a request to a Resource
        along with a few implementations.
      
      - Add PublicResourceUrlProvider to get URLs for client-side use.
      
      - Add ResourceUrlEncodingFilter and
        PublicResourceUrlProviderExposingInterceptor along with initial
        MVC Java config support.
      
      Issue: SPR-10933
      6cb9a144
  7. 08 10月, 2013 1 次提交
  8. 28 9月, 2013 3 次提交
    • R
      Refactor ResourceResolverChain + resolver class names · 3c48b421
      Rossen Stoyanchev 提交于
      This change splits out resource transformation out from the
      ResourceResolverChain so that chain is focused entirely on resource
      resolution (as its name suggests). The invocation of transformers
      is left as a separate step, it uses a different (recursive)
      algorithm in any case and iterates over a different set of objects.
      
      Also ResourceResolverChain is now limited strictly to methods that
      a ResourceResolver should be able to use to delegate to remaining
      resolvers.
      
      Furthermore, ResourceResolverChain now maintains an internal index
      of the "current" resolver so that resolvers don't have to pass the
      chain when invoking it much like a (Servlet API) FilterChain works.
      If the last resolver calls the chain again, a null value is returned.
      3c48b421
    • R
      Polish · 0e58125b
      Rossen Stoyanchev 提交于
      0e58125b
    • J
      Asset pipeline proposal. · 61e61bd5
      Jeremy Grelle 提交于
      61e61bd5
  9. 04 1月, 2013 1 次提交
    • P
      Replace test beans with test objects · 2a30fa07
      Phillip Webb 提交于
      Refactor spring-core tests to replace test beans from
      'org.springframework.beans' with lighter test objects in
      'org.springframework.tests.sample.objects'.
      2a30fa07
  10. 02 1月, 2013 1 次提交
    • P
      Move spring-build-junit into spring-core · 65fb26f8
      Phillip Webb 提交于
      Move code from spring-build-junit into spring-core/src/test along with
      several other test utility classes. This commit removes the temporary
      spring-build-junit project introduced in commit
      b083bbde.
      65fb26f8
  11. 10 8月, 2012 1 次提交
    • C
      Remove spring-asm and inline ASM 4 into spring-core · c16f18a5
      Chris Beams 提交于
      ASM 4.0 is generally compatibile with Java 7 classfiles, particularly
      including 'invokedynamic' instructions. This is important when
      considering that Spring's component-scanning support is internally
      ASM-based and it is increasingly likely that component classes having
      invokedynamic instructions may be encountered and read by ASM.
      This upgrade, then, is primarily preventive in nature.
      
      Changes include:
      
       - upgrade from ASM 2.2.3 to ASM 4.0
      
       - adapt to ASM API changes as necessary throughout spring-core,
         resulting in no impact to the public Spring API.
      
       - remove dedicated spring-asm module
      
       - use new :spring-core:asmRepackJar task to repackage
         org.objectweb.asm => org.springframework.asm as per usual and write
         repackaged classes directly into spring-core jar
      
      The choice to eliminate the spring-asm module altogether and instead
      inline the repackaged classes directly into spring-core is first to
      eliminate an otherwise unnecessary second jar. spring-core has a
      non-optional dependency on spring-asm meaning it is always on the
      application classpath. This change simplifies that situation by
      consoliding two jars into one. The second reason for this choice is in
      anticipation of upgrading CGLIB to version 3 and inlining it into
      spring-core as well. See subsequent commit for details.
      
      Issue: SPR-9669
      c16f18a5
  12. 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
  13. 11 3月, 2010 1 次提交
  14. 01 6月, 2009 1 次提交