- 18 6月, 2019 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Johnny Lim 提交于
Closes gh-23145
-
- 12 6月, 2019 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
Closes gh-23064
-
- 23 3月, 2019 1 次提交
-
-
由 Spring Operator 提交于
This commit updates URLs to prefer the https protocol. Redirects are not followed to avoid accidentally expanding intentionally shortened URLs (i.e. if using a URL shortener). # Fixed URLs ## Fixed Success These URLs were switched to an https URL with a 2xx status. While the status was successful, your review is still recommended. * [ ] http://www.apache.org/licenses/ with 1 occurrences migrated to: https://www.apache.org/licenses/ ([https](https://www.apache.org/licenses/) result 200). * [ ] http://www.apache.org/licenses/LICENSE-2.0 with 6515 occurrences migrated to: https://www.apache.org/licenses/LICENSE-2.0 ([https](https://www.apache.org/licenses/LICENSE-2.0) result 200).
-
- 22 3月, 2019 1 次提交
-
-
由 Spring Operator 提交于
This commit updates URLs to prefer the https protocol. Redirects are not followed to avoid accidentally expanding intentionally shortened URLs (i.e. if using a URL shortener). # Fixed URLs ## Fixed Success These URLs were switched to an https URL with a 2xx status. While the status was successful, your review is still recommended. * [ ] http://www.apache.org/licenses/ with 1 occurrences migrated to: https://www.apache.org/licenses/ ([https](https://www.apache.org/licenses/) result 200). * [ ] http://www.apache.org/licenses/LICENSE-2.0 with 6625 occurrences migrated to: https://www.apache.org/licenses/LICENSE-2.0 ([https](https://www.apache.org/licenses/LICENSE-2.0) result 200).
-
- 19 7月, 2018 1 次提交
-
-
由 Juergen Hoeller 提交于
LinkedList remains in place where a List is likely to remain empty or single-element (in order to avoid unused capacity). Issue: SPR-17037
-
- 27 3月, 2018 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-16646
-
- 07 6月, 2017 1 次提交
-
-
由 Juergen Hoeller 提交于
Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments. Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit. Issue: SPR-15540
-
- 27 5月, 2017 1 次提交
-
-
由 Sebastien Deleuze 提交于
This commit introduces 2 new @Nullable and @NonNullApi annotations that leverage JSR 305 (dormant but available via Findbugs jsr305 dependency and already used by libraries like OkHttp) meta-annotations to specify explicitly null-safety of Spring Framework parameters and return values. In order to avoid adding too much annotations, the default is set at package level with @NonNullApi and @Nullable annotations are added when needed at parameter or return value level. These annotations are intended to be used on Spring Framework itself but also by other Spring projects. @Nullable annotations have been introduced based on Javadoc and search of patterns like "return null;". It is expected that nullability of Spring Framework API will be polished with complementary commits. In practice, this will make the whole Spring Framework API null-safe for Kotlin projects (when KT-10942 will be fixed) since Kotlin will be able to leverage these annotations to know if a parameter or a return value is nullable or not. But this is also useful for Java developers as well since IntelliJ IDEA, for example, also understands these annotations to generate warnings when unsafe nullable usages are detected. Issue: SPR-15540
-
- 27 9月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 30 8月, 2016 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-14577
-
- 05 7月, 2016 1 次提交
-
-
由 Stephane Nicoll 提交于
Issue: SPR-13188
-
- 02 6月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 02 12月, 2015 3 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Rossen Stoyanchev 提交于
-
Fixed a bug where the URL content negotiation "format" parameter values were case sensitive and only lowercase values were accepted. For example, URL query parameter format=json returned the appropriate JSON response but format=JSON resulted in a HttpMediaTypeNotAcceptableException and returned: 406 - The resource identified by this request is only capable of generating responses with characteristics not acceptable according to the request "accept" headers. When the MappingMediaTypeFileExtensionResolver is constructed, it is passed a map containing the media type key to MediaType mappings defined in the ContentNegotiationConfigurer. In the constructor of MappingMediaTypeFileExtensionResolver, the keys are converted to lowercase and the mappings of keys to MediaTypes are added to the ConcurrentMap<String, MediaType> mediaTypes using the lowercase version of the keys. However, when retrieving the MediaType from a key in the lookupMediaType method, no conversion to lowercase is performed so any value for the URL "format" parameter other than the lowercase version will not return the proper MediaType result. On May 1st, 2014, a change was made to ParameterContentNegotiationStrategy to handle cases where the content negotiation format URL parameter does not result in a match for a MediaType. If no match is found, a HttpMediaTypeNotAcceptableException is thrown resulting in the 406 response above. Prior to this commit, a null was returned instead of throwing an exception so this issue was hidden and appeared to function correctly. To make the media type lookup case insensitive, added a line to the lookupMediaType method in MediaTypeFileExtensionResolver to first convert the extension (media type key) to lowercase prior to attempting to retrieve it from the mediaTypes map. Issue: SPR-13747
-
- 30 9月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 02 5月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This change refines the logic of "mapping" content negotiation strategies with regards to how to handle cases where no mapping is found. The request parameter strategy now treats request parameter values that do not match any mapped media type as 406 errors. The path extension strategy provides a new flag called "ignoreUnknownExtensions" (true by default) that when set to false also results in a 406. The same flag is also exposed through the ContentNegotiationManagerFactoryBean and the MVC Java config. Issue: SPR-10170
-
- 14 5月, 2013 1 次提交
-
-
由 Rob Winch 提交于
Issue: SPR-10130
-
- 02 1月, 2013 1 次提交
-
-
由 Chris Beams 提交于
This reverts commit 45fa5082, reversing changes made to a312d900.
-
- 29 12月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-10130
-
- 13 12月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
In particular, avoiding synchronized Sets and Maps wherever possible (preferring a ConcurrentHashMap even instead of a synchronized Set) and specifying appropriate ConcurrentHashMap initial capacities (even if we end up choosing 16).
-
- 26 6月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Following the introduction of ContentNegotiationManager that allows, among other things, to configure the file extensions to use for content negotiation, this change adds "smart" suffix pattern match that matches against the configured file extensions only rather than against any extension. Given the request mapping "/jobs/{jobName}" and one configured file extension ("json"), a request for "/jobs/my.job" will select the pattern "/jobs/{jobName}" while a request for "/jobs/my.job.json" will select the pattern "/jobs/{jobName}.json". Previously, both requests would have resulted in the pattern "/jobs/{jobName}.*". Issue: SPR-7632, SPR-8474
-
由 Rossen Stoyanchev 提交于
Issue: SPR-8410, SPR-8417, SPR-8418,SPR-8416, SPR-8419,SPR-7722
-
- 22 6月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Introduced ContentNeogtiationStrategy for resolving the requested media types from an incoming request. The available implementations are based on path extension, request parameter, 'Accept' header, and a fixed default content type. The logic for these implementations is based on equivalent options, previously available only in the ContentNegotiatingViewResolver. Also in this commit is ContentNegotiationManager, the central class to use when configuring content negotiation options. It accepts one or more ContentNeogtiationStrategy instances and delegates to them. The ContentNeogiationManager can now be used to configure the following classes: - RequestMappingHandlerMappingm - RequestMappingHandlerAdapter - ExceptionHandlerExceptionResolver - ContentNegotiatingViewResolver Issue: SPR-8410, SPR-8417, SPR-8418,SPR-8416, SPR-8419,SPR-7722
-