- 07 9月, 2016 1 次提交
-
-
由 Brian Clozel 提交于
Prior to this commit, the resource handling chain and its `ResourceResolvers` would use specific `Resource` implementations in order to add resource metadata to the HTTP response. For example, `VersionedResource` and `EncodedResource` are both adding specific HTTP response headers. This commit aims at making this mechanism more stable and reusable, since the previous implementation would fail in case a resolved resource would be both a `VersionedResource` wrapping a `EncodedResource` (or the other way arount). Only one of the specific implementations would contribute its metadata since the code supporting that in `ResourceHttpRequestHandler` would only check for `instanceof` tests, whereas those implementations are acutally delegating calls to the wrapped resource. Now both `VersionedResource` and `EncodedResource` have been replaced by specific implementations of `ResolvedResource`, which directly provides those HTTP response headers as part of `getResponseHeaders()`. This commit applies the same changes for the web reactive implementations and its `ResourceWebHandler`. Issue: SPR-14264
-
- 06 9月, 2016 1 次提交
-
-
由 Rossen Stoyanchev 提交于
A straight-forward port of the resource handling support in spring-webmvc to spring-web-reactive. Primarily adapting contracts and implementations to use the reactive request and response and the reactive ResourceHttpMessageWriter. Issue: SPR-14521
-
- 20 7月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-14484
-
- 16 12月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 22 6月, 2015 1 次提交
-
-
由 Brian Clozel 提交于
This change fixes a NullPointerException in GzipResourceResolver, which assumed that calls to the `resolveResource` method were made with only non-null values for request. This is not the case for the VersionResourceResolver, which tries to resolve resources that aren't requested per se by the HTTP request. Issue: SPR-13149
-
- 21 10月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 26 4月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Also respect HandlerMapping order in ResourceUrlProvider
-
- 24 4月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 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 提交于
-