This commit brings back the writeHeaders method on ServerHttpResponse
that was once added (2a6a4f) and then removed (9c7151).
This version is a little simpler since writeHeaders doesn't explicitly
flush/send headers which runtimes are expected to do by default.
Instead the main purpose of writeHeaders now is to ensure changes made
via HttpHeaders are applied to the underlying runtime response at some
point and we now do that once at the very end.
This approach provides the most flexibility (vs keeping HttpHeaders in
sync) because it allows a full and consistent set of mutative
operations for both headers and cookies (to be added) regardless of the
API exposed by the underlying runtime.
This change adds a WebServerExchange and updates all contracts at the
the same level (i.e. org.springframework.web.server) as well as the
org.springframework.web.reactive level to use it so that all
framework-related code will have access to server-side processing
features such as request attributes (and others to come).
This change separates out lower-level HTTP adapter code from the more
(framework-specific) HTTP processing into a separate package under
org.springframework.web.server (not under org.springframework.http).
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)
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.
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.
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.
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.
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.
This change also removes reactor-stream variants of the request and
response since the request and response aren't used directly by
application code and get passed through reactor.Publishers anyway.
This is needed in order to be able to use Spring Reactive in standalone
applications. These are temporary classes that will return in
src/test/java when Spring Boot support for Reactive applications will
be implemented.
reactive.codec -> core.codec
reactive.io -> util
These may very well not be the final locations. For now they simply
express that there are classes that belong somewhere in core, i.e.
they are lower level dependencies than web.
RequestMappingHandlerMapping currently picks the first match and does
have logic to deal with selecting the best match. This caused a
random test failure depending on which controller method was matched
first. This change removes the test.
The web related code is now under org.springframework.web.reactive.
This is parallel to org.springframework.web (the top-level package of
spring-webmvc).
This change allows to be able to check generic type on the return value
at HandlerAdapter and ResultHandler level. For example, it allows to do
a Publisher<Void> check in SimpleHandlerResultHandler.
"Content-Type" is just a single MediaType.
For the response, the MediaType must be fully selected before
selecting and encoder.
The ResponseBodyResultHandler now includes actual content negotiation
with a potential 406 response.
This commit introduces the following changes:
- MessageToByteEncoder/Decoder renamed to Encoder/Decoder
- JsonObjectEncoder/Decoder are now used directly in
JacksonJsonEncoder/Decoder
- Codec uses MimeType instead of MediaType since they
are not specific to HTTP
- Default MimeType are now managed thanks to
Encoder/Decoder#getSupportedMimeTypes()
- AbstractEncoder/Decoder takes care of generic MimeType related behavior
This commit introduces the following changes:
- Publisher -> Observable/Stream/etc. conversion is now managed
in a dedicated ConversionService instead of directly in
RequestBodyArgumentResolver and ResponseBodyResultHandler
- More isolated logic that decides if the stream should be
serialized as a JSON array or not
- Publisher<ByteBuffer> are now handled by regular
ByteBufferEncoder and ByteBufferDecoder
- Handle Publisher<Void> return value properly
- Ensure that the headers are properly written even for response
without body
- Improve JsonObjectEncoder to autodetect JSON arrays
Replace Streams fail, empty and Stream map with Publishers.error, empty and map.
Replace Streams calls by Publishers.flatMap, just and Publishers.from
Precise cancel and size to toReadQueue to simulate Promise
Update build
This commit updates HandlerAdapter#handle() to return HandlerResult
instead of Publisher<HandlerResult>. A new SimpleHandlerResultHandler
class has been introduced for handlers returning Publisher<Void>.
This commit adds support for Publisher based codecs that allows to convert
byte stream to object stream and vice & versa.
Jackson, JAXB2 and String codec implementations are provided.
Just enough for a test with an @ResponseBody method that accepts an
@RequestParam String arg and returning Publisher<String> or String.
See RequestMappingIntegrationTests.
This commit adds support for simple URL handler mapping (exact path
match) and an adapter for the HttpHandler interface to be used to
handle the request.
The SimpleUrlHandlerMappingIntegrationTests then maps the URLs
"/foo" and "/bar" to two different handlers.
This is a refactoring of the existing "echo" integration test with the
goal to make it easier to add further integration tests.
The HttpServer abstraction is on the test source side for now.
Introduce http and dispatch packages under org.springframework.web to
separate HTTP-specific adapter code from higher level web framework
code. Move classes into their respective locations.
HandlerMapping, HandlerAdapter, HandlerResultHandler (+ HandlerResult)
as the basic request handling contracts. DispatcherHandler to drive
overall request handling.
DispatcherApp provides minimal implementations of the above contracts
enough to put together a running example that returns
200 text/plain "Hello world".
This commit adds RxNetty integration that includes RxNetty-based
implementations of ServerHttpRequest and ServerHttpResponse as well as
an adapter from the RxNetty RequestHandler to the HttpHandler contracts.
Only byte[] is supported at the moment for reading and writing with a
corresponding copy to and from Netty ByteBuf.
This commit introduces HTTP request and response abstractions along
with Servlet-based implementations similar to the ones in the http
package of spring-web but using Reactive Streams.
In turn HttpHandler now accepts the request and response types and
returns Publisher<Void> that reflects the end of handling.
The write method on the response also returns Publisher<Void> allowing
deferred writing. At the moment however the underlying Servlet 3.1
support only supports a single publisher after which the connection
is closed.
Only simple byte[] is supported for reading and writing.
For Tomcat, failures occur if HttpHandlerServlet buffer size is
significantly less than the Tomcat input buffer size.
Also on command line Jetty tests fail with port unavailable unless
the server from the Tomcat tests is also destroyed.
Sebastien Deleuze
Rossen Stoyanchev
Stephane Maldini
Marek Hawrylczak
Arjen Poutsma
Stephane Maldini
João Pedro Evangelista