Added support for function parameter type Collection
Updated both Jackson and Gson mappers
Defined a new toObject() operation on JsonMapper and deprecated the old
Resolves#210
We want the default application type to be REACTIVE if webflux is
present (formerly it was NONE). In AWS and Azure we also want
the webflux beans to be switched off in a "lite" application
context (formerly they were unconditional).
User can run a minimal HTTP app using an app that is a Function
or an ApplicationContextInitializer. Can also test using
@FunctionalSpringBootTest in place of @SpringBootTest.
Add some tests and documentation for functional beans
Make server.address configurable
MVC and Webflux share some common business logic
so it makes sense to put them in the same module.
Also simplifies the MVC code, removing the custom argument
and return value handlers.
Weed out unecessary method param
Unignore some tests
There is now a JsonMapper strategy with implementations and
autoconfiguration for Gson and Jackson. If Jackson is present
it is preferred (just like in Spring Boot).
Fixes gh-150
This results in a better experience for users because the consumer
that they write is only applied to a Flux that is subscribed to
by the framework once. It gives better control over the flow of
foos, e.g. if some component wants to subscribe on a thread.
User can switch off source or sink behaviour (the default is to bind
to input and output streams), and then configure the name of a
supplier (for a source) or consumer (for a sink).
With this change there are now 2 choices for web endpoints. The
stream servlet binder is useful for multi-binder use cases
(e.g. HTTP -> message broker).
A registered singleton doesn't have a BeanDefinition, but it might have
a compiled type with enough generic information to pull out the
input and output types.
If the output is a Message we grab the headers from the first one
and send those as response headers.
A function can add headers to messages. The HTTP response will
contain only headers that are in x-* _or_ were added to the message
by user (i.e. they weren't in the request).
We certainly do not want to pass through all HTTP headers (request
headers can conflict with or invalidate response headers).
Compiled functions always show up with no metadata, and you can only
guess what the types are from the bean definition. Probably we should
add more information to the bean definition if we have it when we
compile the function.
There is still a problem if user defines functions that are not of
Flux<String> (but that has always been the case).
If the request is a single value, we already know, so if we also
know that the function returned a single-valued type, then we can
render the single value, instead of an array with a single item.
See gh-36
So that single Strings can be POSTed without JSON conversion.
There's still some work to do to support single POJOs in JSON, and
to reach parity with the WebFlux reactive type handlers, but it's
now closer to what we had before we moved the String conversion
out of the function layer.
When the user has sent us a single value, we can make the signature
of the handler and the format of the HTTP response much more
natural if it is single valued too (i.e. a Mono).
An HTTP response does not have to be an infinite stream, and in fact
life is simpler if it is not. The timeout in the web wrappers can
be used to close the response and return normally to a client
that has been waiting more than (say) 1s, instead of treating
it as an error condition.
Error handling is still kind of unsolved.
