A registered singleton doesn't have a BeanDefinition, but it might have
a compiled type with enough generic information to pull out the
input and output types.
Stops application from blowing up if there are messages available
on startup and the broker is not there. There are still errors
(failed messages), but it doesn't stop the app from starting.
Maybe should be optional to fail fast?
It didn't really make any sense to have custom conditions that
depend on the presence or absence of beans of type Function,
Supplier, Consumer because the actual endpoints are derived
from the FunctionCatalog (which might not be based on
bean definitions). This approach is far simpler, and
reduces the amount of custom code in the stream binder.
The spring.cloud.function.stream.supplier.enabled flag
is awkward, so we should try and find a way to avoid that.
There's also no reason it should need to be set in the
deployer tests.
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.
* If there is only one function, use it unconditionally
* If no functions match, ensure that null is not the selector
* If a conversion succeeds, check the type of the result
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.
If there is only one function you shouldn't have to set any configuration
to get a stream app to run. This also implementation supports multiple
functions, trying to guess which one to use based on the type of
the incoming message payload. In principle that could be strategized
as a simple router function (e.g. to look for a header with a function
name).
If there are functions and consumers in the same app, they will
subscribe to the same input channel (and hence by default Spring
Integration will load balance between them). This could also probably
use some more features, to specify the desired behaviour.
If user *does* supply spring.cloud.function.stream.endpoint then it
is used and overrides all other possible routes.
- 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)
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
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.
User can POST to web endpoint in SSE style, i.e:
HTTP/1.1
Content-Type: text/event-stream
data:foo
data:bar
Will be converted to a Flux with values foo and bar
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)
