- Removed constructor in InMemoryFunctionCatalog that creates empty maps and no registrations since there is no way to register anything after catalog is created.
- Refactored registration logic a bit more functional/concise in the FunctionRegistration constructor of InMemoryFunctionCatalog
- Added additional assertions in tests
rebased and removed the assertion that was causing certain test failures
If the incoming message has a stream_routekey header, we use that
to route the message to a named function. Also adding the header
to messages coming out of suppliers.
The biggest change here is sort of orthogonal: it fixes a bug where
Spring Integration would subscribe twice to the same input channel
if the FunctionCatalog contains both functions and consumers. Then
when a message comes in it is dispatched to one or the other, but not
both. So the routing key couldn't work without fixing that
problem.
Also applies to output types, wrapper types and identifying if
messages can be processed directly.
See gh-81 (the ambiguity is still there, but the indirection bug
is fixed).
The FunctionInspector needs to be able to distinguish between a
function of Flux<Foo> and a function of Flux<Message<Foo>>. Then
it can do the conversion a level below.
Only supports Message->Message or POJO->POJO (no mixtures), so there
is only one new method in FunctionInspector.
No support in the web endpoints yet. But it's probably not so hard
to add.
The compiled functions implement that interface which means you can inspect
the signature of the method that created them and discover its
generic types.
Compiled functions always show up with no metadata, and you can only
guess what the types are from the bean definition. Probably we should
add more information to the bean definition if we have it when we
compile the function.
There is still a problem if user defines functions that are not of
Flux<String> (but that has always been the case).
These can be used to more reliably discover whether the user
has declared a function with flux types or "bare" POJOs. They
then pave the way to supporting single valued types in a special
way.
Also consolidate and simplify the logic in FunctionInspector
So that single Strings can be POSTed without JSON conversion.
There's still some work to do to support single POJOs in JSON, and
to reach parity with the WebFlux reactive type handlers, but it's
now closer to what we had before we moved the String conversion
out of the function layer.
There is one behaviour change (you have to POST an array to a function
endpoint if you are sending a body), and also a message converter that
needed to be removed so that arrays are not toStringed in the response
body.
- use ProxyWrapper around a FluxConsumer as well
making it consistent with the behaviour of Flux
functions
- Enable introspection for scanned beans
- Fix failing tests by passing JSON string as input messages
(marshalled form expected from the binder)
A bean of type FunctionRegistration registers the function with
user-specified name and other properties, rather than relying on the
bean name.
Alternatively, function catalog keys can be specified as a
@Qualifier, which will be used instead of the bean name if
no registration is found.
Polished POM files to remove redundant entries that were causing warnings in the IDE. Some notable changes are:
- Removed spring-boot.version from sample project as they inherit it from the parent
- Removed versioning for maven-jar-plugin (was 3.0) from multiple project so it relies on the managed version
- Removed java.version from all spring-cloud-function-* modules as they inherit the one from parent.
Addressed PR comments
- removed references to maven-jar-plugin
Beans that are not created from a @Bean factory method do not have
the same kind of metadata. This change uses relection to extract
the target type from the bean definition if all else fails.
We don't need to cover all the possible uses of Flux (only
Flux<String> really), so this isn't comprehensive coverage of
all the features in Spring WebFlux, but it's good enough for
functions to run with Spring Boot 1.5.
Should be easy enoug hto add back later, but it was causing issues
with type conversion where we are npot yet sophisticated enough
to chain functions together and keep track of the types being
passed between them.
Make it deployable via its maven coordinates in
spring-cloud-function-deployer (it is deployed by default on start
up right now, but that's just a demo)
