On windows when walking through jar contents some files use
forward slashes and some backslashes. With this change we
switch to a consistent usage of forward slashes throughout
(converting backslashes to forward when necessary). With these
changes the testsuites work on windows.
- attempted to make code more functional (eat our own dog food) and concise
- addressed PR comment
- additional cleanup/polishing of FunctionUtils and related classes
- Removed Function/Supplier/ConsumerProxy classes by extending type info on their super interface
- Renamed FunctionUtils to FunctionFactoryUtils
- Added javadoc to FunctionFactoryUtils to explain its design considerations as well as what it can and can not doi
Fixes gh-90
- minor refactoring of FunctionRegistration and some javadoc
- general cleanup of ContextFunctionCatalogAutoConfiguration (mainly consolidated repeatable code)
Fixes gh-98
- removed Function/Supplier/ConsumerFactories by modifying SOURCE_CODE_TEMPLATE
- removed Example main from src/main/java/org.springframework.cloud.function.compiler
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.
- 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).
Functions are namespaced under the "app name", e.g.
/sample/uppercase is the "uppercase" function in the "sample" app.
Also added a README to get started quickly.
The controller doesn't need to know the mappings, and it helps
to keep them closer to the actual AppDeployer, so in a future
change we can use the app names to look up functions.
* 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
Spring Boot apps often run with --debug (no boolean value), so
we need to be defensive and not barf if it's empty (and therefore
not convertible to a boolean)
The io.spring sample referred to in the openwhisk README isn't
in this repo, so users generally don't have it installed locally.
This change makes it more obvious that you have to create your
own.
Also fixes the `wsk ...` command lines (the order of arguments
was wrong - maybe the CLI changed?).
If the output is a Message we grab the headers from the first one
and send those as response headers.
A function can add headers to messages. The HTTP response will
contain only headers that are in x-* _or_ were added to the message
by user (i.e. they weren't in the request).
We certainly do not want to pass through all HTTP headers (request
headers can conflict with or invalidate response headers).
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.
