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.
Ensured that the default instance of ObjectMapper is created in the event ObjectMapper configuration is missing (i.e., JacksonAutoConfiguration) in AWS adapter
Resolves#188
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.
There is only one version of amazon-kinesis-deaggregator available
in Maven Central, which is unfortunate because it brings in an
older version of the AWS events API, which in turn has a very bad
version range specification, causing the whole AWS internet to
be downloaded for each build.
I also made the deaggregator optional, which will help. Users that
want to include it shoudl consider doing the same exlcusion.
Fixes gh-171
The current implementation of SpringBootKinesisEventHandler only handles
non-aggregated events. Attempting to process aggregated events caused
ungraceful failure.
This commit fixes that by de-aggregating any events before performing
conversion. Non-aggregated events are still handled transparently.
In addition, detection of Message<T> input is performed, and
output messages are wrapped accordingly.
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.
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.
