Added logic in FunctionalSpringApplication to avoid registering the functional bean twice. This issue occured when executing in "hybrid" mode, and using the same bean as both the application context source and functional bean.
- Added wrapper for an already reactive consumer to ensure that consumers can be consistently represented as Function<Flux, Mono>
- Fixed the big that deal with inconsistent result in web environments due to inconsistent representation of the Consumers
- Polished tests
Resolves#243Resolves#257
Added spring.cloud.function.definition property which is used by FunctionRegistry as a supplement instruction to resolve nameless lookups.
It is used by web module to map single or multiple (composed) functions to the root path (/)
Resolves#247
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.
Reoved FunctionScan annotation since it provides no additional value to the end user
Preserved auto component scanning for Functions in package
Updated filter to additionally scan for Supplier and Consumer
Resolves#232
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
SpringApplication looks like the class with the same name in Spring
Boot (and is a subclass of it), but it checks to see if the user
is asking for functional bean registrations and only used those if
it can.
The problem with a BPP that processes FunctionRegistration is that
they might not be instantiated before the FunctionRegistry. It is
better to enforce the dependency order we need by injecting the
registrations explicitly but lazily into the registry.
Undeprecated deprecated constructor in FunctionRegistration
Made FunctionRegistration BeanNameAware
Added name assertion in FunctionRegistrationPostProcessor
