- 08 1月, 2016 5 次提交
-
-
由 Rossen Stoyanchev 提交于
Refine exception handling responsibilities between the DispatcherHandler and the HandlerAdapter.
-
由 Stephane Maldini 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
This reverts commit d5e6f70483d4a6c8af3cc5e97e52a54e98199169.
-
- 07 1月, 2016 3 次提交
-
-
由 Sebastien Deleuze 提交于
-
由 Sebastien Deleuze 提交于
-
由 Sebastien Deleuze 提交于
Flux and Mono are used both for implementation and exposed at API level to express 1 versus N semantic and to provide default Rx operators: - Flux<T> for multiple values Publisher (issue #48) - Mono<T> for single value Publisher (issue #50) - Mono<Void> for Publisher with no value (issue #49)
-
- 01 1月, 2016 3 次提交
-
-
由 Rossen Stoyanchev 提交于
For those runtimes that don't directly support Reacitve Streams this commit separates more formally Reactive Streams bridge code out of the request and response implementations which become simple adapters to the ServerHttpRequest/Response contracts like their RxNetty and Reactor Net counterparts.
-
由 Rossen Stoyanchev 提交于
- 30 12月, 2015 7 次提交
-
-
由 Rossen Stoyanchev 提交于
ServerHttpResponse implementations now immediately propagate HttpHeaders changes as they so there is no need to call applyHeaders(). The writeHeaders from ServerHttpResponse is also removed. RxNetty and Reactor Net both support implicitly completing if the handler completes without explicitly writing the headers or the response body.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
The "rxnetty" artifact is old (October 2015). There is now rxnetty-http and other modules that have more recent snapshots (December 2015).
-
- 19 12月, 2015 1 次提交
-
-
由 Stephane Maldini 提交于
-
- 17 12月, 2015 3 次提交
-
-
由 Stephane Maldini 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
- 16 12月, 2015 4 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
The DispatcherHandler now has an errorMapper property that is a function for transforming errors. By default this property is set to an instance of DispatcherHandlerExceptionMapper which wraps "standard" framework exceptions and @ResponseStatus-annotated exceptions as ResponseStatusException. This makes it easy to handle the exceptions downstream uniformly.
-
由 Rossen Stoyanchev 提交于
This change adds a ResponseStatusException to associate an exception with a status code at runtime. Along with that is an ResponseStatusExceptionHandler that handles ResponseStatusException by setting the response status.
-
- 11 12月, 2015 4 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
The tests demonstrate failures at various phases of request processing and the resulting error signals.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
- 09 12月, 2015 5 次提交
-
-
由 Sebastien Deleuze 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Stephane Maldini 提交于
-
由 Rossen Stoyanchev 提交于
It brings along Servlet imports.
-
- 08 12月, 2015 2 次提交
-
-
由 Stephane Maldini 提交于
-
由 Rossen Stoyanchev 提交于
General improvements e.g. make use of Java 8 Stream. The main reason for the refactoring however to tighten error handling. To that extent: InvocableHandlerMethod turns all exceptions into Reactive Streams error signals, in effect never allowing any Exceptions to bubble up. HandlerMethodArgumentResolver may throw an Exception for sync resolution or produce an error signal via the returned Publisher. Either way the exception is consistently wrapped with helpful method argument details. For the latter case using a custom mapError operator. HandlerMethodArgumentResolver no longer needs to return Optional for nullable argument values. Instead (for now) the defaultIfEmpty operator of reactor.rx.Stream operator is used to ensure a default constant value (called "NO_VALUE") is produced. That way an argument resolver may produce 0..1 values where 0 means it did not resolve to any value and that results in null passed as the argument value. If a HandlerMethodArgumentResolver produces more than one value, all additional values beyond the first one will be ignored with the help of a custom "first" operator. As HandlerMethod is invoked within the map operator, checked exceptions are not allowed but instead of wrapping it in a runtime exception what we really need is to unwrap the target exception for exception resolution purposes. To this end concatMap is used to produce a nested Publisher or an error Publisher with the unwrapped target exception. Related to that InvocableHandlerMethod now returns Publisher<HandlerResult> instead of Publisher<Object> so that no longer needs to be externally mapped from Object to HandlerResult. InvocableHandlerMethodTests provides tests for the above scenarios and verifies the details of resulting error signals.
-
- 07 12月, 2015 1 次提交
-
-
由 Sebastien Deleuze 提交于
This commit also updates to the following dependencies: - Spring Framework 4.2.3.RELEASE - RxJava 1.1.0
-
- 03 12月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 02 12月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-