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
Flux.from() is cheap and can be used to marshal the inputs everywhere
internally. With this change users ought to be able to register any
function of any Publisher type.
It tends to pop back into function apps where it is not needed
otherwise. Users that want to use the library need to import
the FunctionConfiguration directly using the
@EnableFunctionDeployer convenience annotation..
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).
A Spring Boot 2.0 app should behave the same as a Spering Boot 1.5
app with this change. The key thing was to change the return type
of the FunctionController and move the computation of single
valuedness for the output there (instead of trying to do it in the
return value handler, which isn't used in Spring 5).
Makes it possible to support other "function" types in the future.
The user is always taking a risk with the lookup that the object
returned has the generic type desired (but that hasn't changed
with this commit). FunctionCatalog is a lot simpler as a result
and also a lot more flexible.
The web module doesn't really need to depend on tomcat and all of
the Spring Boot web stack, but users need a way to grab that stuff
quickly if they want it (hence the new starter).
Also removed all spring-boot-starter dependencies from core and
context modules.