- 09 9月, 2016 2 次提交
-
-
由 Arjen Poutsma 提交于
Prior to this commit, FreeMarkerView used the system default charset to render. This commit switches this by defaulting to UTF-8, if no charset is specified in the content type. - Add contentType parameter to AbstractView.renderInternal, used to determine the charset contained therein - Adds a defaultCharset property to AbstractView and ViewResolverSupport.
-
由 Arjen Poutsma 提交于
Changed View's render method from taking a HandlerResult to taking a Map<String, ?>, in order to facilitate scenarios where a HandlerResult is not available (i.e. web.reactive.function).
-
- 03 9月, 2016 1 次提交
-
-
由 Brian Clozel 提交于
This commit fixes `ResponseEntityResultHandler` so that it only tries to call `writeBody` if the `ResponseEntity` is not null. In case the response entity body is null, the response is flushed right away and the request is signaled as handled. Issue: SPR-14663
-
- 02 9月, 2016 3 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-14522
-
由 Rossen Stoyanchev 提交于
Issue: SPR-14522
-
由 Rossen Stoyanchev 提交于
Issue: SPR-14658
-
- 31 8月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-14646
-
- 30 8月, 2016 1 次提交
-
-
由 Brian Clozel 提交于
Prior to this commit, exceptions thrown by the `HandlerMethodArgumentResolver` would be wrapped into `IllegalStateException`s. This commit makes sure that a DEBUG log is written with the relevant information and that the root cause is not wrapped into another exception, so that the appropriate `ExceptionHandler` can be used to deal with this error. Issue: SPR-14618
-
- 29 8月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
-
- 09 8月, 2016 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 28 7月, 2016 3 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
There is really no need for a result handler dedicated to a void return value and it's actually problematic to have it. Each result handler treats void as necessary. For an @ResponseBody method it means an empty body. For view resolution it means no specific value was returned and we should procede with selecting a default view name. Having a dedicated void result handler can interfere with this especially since view resolution needs to be last in order. At the same time there are cases when no result handling is needed and the response is fully handled within the HandlerAdapter. This is the case with WebHandler and the SimpleHandlerAdapter. For that case we simply return mono.then(aVoid -> Mono.empty()) which effectively returns an empty Mono and no result handling follows. The HandlerAdapter already says you can return no values at all if the response is fully handled.
-
- 23 7月, 2016 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Issue: SPR-14159
-
- 19 7月, 2016 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Ensure type-level Javadoc in every class, comply with guidelines for 80 char on Javadoc, and minor polish.
-
- 15 7月, 2016 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
- 08 7月, 2016 2 次提交
-
-
由 Rossen Stoyanchev 提交于
This commit adds support for handling an empty request body with both HttpEntity where the body is not required and with @RequestBody where the body is required depending on the annotation's required flag. If the body is an explicit type (e.g. String, HttpEntity<String>) and the body is required an exception is raised before the method is even invoked or otherwise the body is passed in as null. If the body is declared as an async type (e.g. Mono<String>, HttpEntity<Mono<String>>) and is required, the error will flow through the async type. If not required, the async type will be passed with no values (i.e. empty). A notable exception is rx.Single which can only have one value or one error and cannot be empty. As a result currently the use of rx.Single to represent the request body in any form effectively implies the body is required.
-
由 Rossen Stoyanchev 提交于
The RequestBodyArgumentResolver has been refactored to have a shared base class and tests with the new HttpEntityMethodArgumentResolver. An HttpEntity argument is not expected to have an async wrapper because the request headers are available immediately. The body however can be asynchronous, e.g. HttpEntity<Flux<String>>.
-
- 07 7月, 2016 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
- 04 7月, 2016 3 次提交
-
-
由 Sebastien Deleuze 提交于
-
由 Rossen Stoyanchev 提交于
When using the ConversionService to check and bridge to and from reactive types we now generallly provide the full type information available from method signatures. However that full type information is not always necessary such as when we perform additional checks on the generics of the reactive type (e.g. Mono<ResponseEntity>). This allows us to switch to use DefaultFormattingConversionService instead of GenericConversionService while also ensuring that the CollectionToObjectConverter doesn't think it can convert List<?> to any reactive type. The ObjectToObjectConverter can also interfere because it is smart enough to find the "from(Publisher<?>)" method on Flux and Mono. To make up for that on the response side we now check if a type is assignable to Publisher first in which case it is a simple cast. In turn that means we don't need a PublisherToFluxConverter which can be problematic in its own right because it can convert from Mono to Flux which technically doesn't lose data but switches stream semantics. Issue: #124, #128
-
由 Rossen Stoyanchev 提交于
HandlerAdapter's should always be able to provide a MethodParameter which in turn ensures that HandlerResultHandler's have full type information from method declarations. This commit also introduces ResolvableMethod for use in tests to make it easy to obtain MethodParameter return types. Issue: #128
-
- 02 7月, 2016 5 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
This commit ensures stream semantics (Flux vs Mono) are adhered to also on the target side.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Sebastien Deleuze 提交于
This commit adds a Decoder#decodeOne() method in order to handle correctly the streaming versus one value deserialization based on the type provided by the user. For example, if a List parameter is provided in a controller method, Jackson will be called once, while if the user provides a Flux or an Observable parameter, Jackson will be called for each element.
-
- 01 7月, 2016 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 30 6月, 2016 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This is a port of the following commit, adapted for Java 8+: https://github.com/spring-projects/spring-framework/commit/89396ff01ff159aa7df18e332f3888cf9ce3dc20
-
- 27 6月, 2016 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Currently ResponseEntityResultHandler is ordered lower than ResponseBodyResultHandler by default whch means a ResponseEntity should not be picked by the ResponseBodyResultHandler. However as it is easy to have both ResponseEntity and @ResponseBody e.g. in @RestControler (or even by mistake) and in general it makes sense for ResponseBodyResultHandler to explicitly recognize and ignore the ResponseEntity return type.
-
- 25 6月, 2016 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Before this commit only ResponseEntity with async body was supported, e.g. ResponseEntity<Mono<String>> This commit also adds suppport for an asyn wrapper around, e.g. Mono<ResponseEntity<String>.
-
由 Rossen Stoyanchev 提交于
Introduce separate test classes for each base class in the hierarchy above @ResponseBody and ResponseEntity result handlers. Also start porting existing unit test cases for @ResponseBody and ResponseEntity return value handlers.
-
- 22 6月, 2016 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 11 6月, 2016 3 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-