- 04 6月, 2016 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
- 02 6月, 2016 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Removed in favor of accessing the factory from the response.
-
由 Rossen Stoyanchev 提交于
After the fix for ReactiveX/RxNetty#509 we can remove the workaround to concatenate with an empty Observable for the request body and upgrade to the latest RxJava 1.1.5. Issues: #103
-
- 01 6月, 2016 8 次提交
-
-
由 Sebastien Deleuze 提交于
-
由 Rossen Stoyanchev 提交于
The converters release so this is the right thing to do, not a temporary fix.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
ViewResolutionResultHandler and ResponseBodyResultHandler now share a common base class ContentNegotiatingResultHandlerSupport that supports content negotiation. For view resolution we compare against the supported media types of resolved View instances, which may include default View's delegating to an HttpMessageConverter (e.g. JSON, XML, rendering).
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
View now returns Mono<Void> rather than Flux<DataBuffer> which aligns more closely with the reactive HttpMessageConverter vs the Encoder. The change was prompted by the upcoming implementation of a View that delegates to an existing HttpMessageConverter e.g. for JSON, XML. The resulting change also brings the reactive View closer in spirit to the View from spring-webmvc which returns void.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
The ContentNegotiatingResultHandlerSupport base class encapsulates the logic for content negotiation needed for both @ResponseBody and view resolution result handling.
-
- 31 5月, 2016 2 次提交
-
-
由 Stephane Maldini 提交于
-
由 Stephane Maldini 提交于
-
- 30 5月, 2016 2 次提交
-
-
由 Sebastien Deleuze 提交于
-
由 Sebastien Deleuze 提交于
-
- 28 5月, 2016 4 次提交
-
-
由 Rossen Stoyanchev 提交于
This commit adds support for Model-related return values types such as Map, Model, @ModelAttribute annotated, and non-simple types, which helps to clarify the logic in ViewResolutionResultHandler.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Remove handler inserted at the end to generate error in favor of doing the same using the otherwiseIfEmpty operator.
-
- 27 5月, 2016 14 次提交
-
-
由 Brian Clozel 提交于
And change the defaults to: * "0.0.0.0" for the host * any available port, starting at 8080
-
由 Arjen Poutsma 提交于
-
由 Arjen Poutsma 提交于
-
由 Arjen Poutsma 提交于
In order to be more "reactive", changed StringDecoder's default from merging all buffers in the stream to a single buffer into splitting the buffers along newline (\r, \n) characters.
-
由 Arjen Poutsma 提交于
This commit introduces DataBuffer.indexOf(IntPredicate) and lastIndexOf(IntPredicate), for finding the index of a byte in a DataBuffer. It also introduces DataBufferUtils.tokenize, which tokenizes a DataBuffer into separate tokens, given a delimiter function.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
This commit ensures correct handling for Mono.empty() return value where the declared return type is Mono<String> or Mono<View>.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
While View and ViewResolver play the same role as in spring-webmvc they are now abstracted behind the HandlerResultHandler abstraction so that top-level contracts don't reference them and the DispatcherHandler is also unaware of their existence. Furthermore view resolution and response body handling which are now at the same level of abstraction (each is a HandlerResultHandler) will also share code for content negotiation, so it makes sense for them to be side by side. This commit moves the reactive.view package to reactive.result.view with the View and ViewResolver contracts (previously in the top-level reactive package) also moving there.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
- 26 5月, 2016 4 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
When a null is returned from an @ResponseBody method, rather than returning Mono.empty() immediately, convert it to Mono.empty() and apply the same processing. Currently that doesn't make a practical difference but it's more accurate to do it this way. Eventually it may mean the possibility to turn empty values into something through an extension point as we do with ResponseBodyAdvice in Spring MVC today.
-
由 Rossen Stoyanchev 提交于
-
- 12 5月, 2016 2 次提交
-
-
由 Stephane Maldini 提交于
-
由 Stephane Maldini 提交于
-