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.
The function compiler knows how to extract jars nested inside
a Spring Boot fat jar. It's really slow (so that's maybe another
problem for another day), but it works now.
Fixes gh-115
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?
- Removed EmptyIterable as it's only used by _MemoryBasedJavaFileManager_
to ensure the contract of the _list(..)_ operation that must not return
null. The same contract is ensured with _new
IterableClasspath(classpath, packageName, recurse)_ while making
_MemoryBasedJavaFileManager.list(..)_ simpler and more consistent.
- Untill this fix the AbstractByteCodeLoadingProxy was building FQCN of
the byte-array defined class using Resource.getFileName() and then some,
which is not very reliable since if such name does not match the actual
name contained in the byte code, class loading will result in exception.
So, this fix reads FQCN from the actual byte code..
- Reduced visibility of AbstractByteCodeLoadingProxy
- Simplified ByteCodeLoadingFunctionTests
Closes gh-99
Also strips out repositories and profiles and other stuff that users
don't need in their dependency management. And adds the license
and project metadata automatically.
See also gh-109. So there is a TODO in there to fix the configuration
and when the thin launcher 1.0.7 comes out we should update the version
as well. But it's working now, and quite similar to the Maven output,
except for the thin.properties.
Fixes gh-108
They all work except the AWS one, where the shadow plugin seems to
prang the thin launcher one. Removing the thin plugin gets us
something that works.
Fixes gh-105
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).
