- 16 12月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 21 10月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 28 5月, 2014 1 次提交
-
-
由 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
-
- 26 4月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Also respect HandlerMapping order in ResourceUrlProvider
-
- 22 4月, 2014 1 次提交
-
-
由 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
-
- 17 4月, 2014 1 次提交
-
-
由 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
-
- 08 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This reverts commit d4a0e628, reversing changes made to 8abe9497.
-
- 28 9月, 2013 3 次提交
-
-
由 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.
-
由 Rossen Stoyanchev 提交于
-
由 Jeremy Grelle 提交于
-
- 04 1月, 2013 1 次提交
-
-
由 Phillip Webb 提交于
Refactor spring-core tests to replace test beans from 'org.springframework.beans' with lighter test objects in 'org.springframework.tests.sample.objects'.
-
- 02 1月, 2013 1 次提交
-
-
由 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.
-
- 10 8月, 2012 1 次提交
-
-
由 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
-
- 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
-
- 11 3月, 2010 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 01 6月, 2009 1 次提交
-
-
由 Chris Beams 提交于
* Applied patch submitted by Carlos Zuniga
-