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
Updated both the interface as well as InMemoryFunctionCatalog BeanFactoryFunctionCatalog and SingleEntryFunctionRegistry implementations
Added tests
Resolves#199
Some tests still ignored.
Also adds draft functional bean registration support. The AWS sample
is using that now (it starts up 4x faster in AWS). To activate the
functional beans user has to supply a main class of type
ApplicationContextInitializer.
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.
Using this strategy libraries could be developed for supporting
Flux-like libraries (e.g. kstreams) that are not actually
reactive streams implementations.
If an isolated function doesn't have Message in its classpath, we
will never actually need to instantiate that class. This change
makes sure we check first.
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.
Avoids instantiating beans if not necessary, and allows user to
provide Function as a @SpringBootApplication (for instance), or
more generally as a source to the application context (as opposed
to being component scanned).
When a Supplier<Flux<Foo>> is composed with a Function<Foo,Bar>
the resulting handler (supplier) should have Flux as its output
wrapper still (the most general output wrapper type in the chain).
