This is useful for example if the user is taking care of the
functional bean registration in some other way, and still wants to
use spring.functional.enabled=false to control that.
Resolves#233
Happens when HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTES is null
Can be seen when using spring-boot-starter-actuator with a scanned function
The path is null because the request wrapped by the WebMvcMetricsFilter is unmodifiable,
so setting the attribute in AbstractHandlerMethodMapping#handleMatch has no effect
User can now provide a Function or an ApplicationInitializer. Also
the initializer can create a FunctionRegistration with the handler
name instead of a bean with the handler name. Better control of
input and output types that way.
Fixes gh-231
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
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).
