Use of BeanProcessor to catch a bean before it is used is a bit
agricultural these days. SmartInitializingSingleton is better and
frees application logs from one more annoying INFO log on an
early instantiation
2018-01-04 14:17:05.930 INFO 23472 --- [ Thread-0] trationDelegate$BeanPostProcessorChecker :
Bean 'org.springframework.cloud.function.web.flux.ReactorAutoConfiguration' of type
[org.springframework.cloud.function.web.flux.ReactorAutoConfiguration$$EnhancerBySpringCGLIB$$8d4844e]
is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
With this change there are now 2 choices for web endpoints. The
stream servlet binder is useful for multi-binder use cases
(e.g. HTTP -> message broker).
Fixes: gh-118
When the `BeanDefinition` for `Function` is a `FactoryBean`
(e.g. `GatewayProxyFactoryBean` in Spring Integration) and that
`BeanDefinition` isn't registered as `@Bean` method (e.g.
Spring Integration Java DSL parser), the `ContextFunctionCatalogAutoConfiguration`
doesn't resolve the target `Function` type properly
* Get the target `Function` bean type via `BeanFactory.getType(String)`
* Make fallback to the `Object.class` instead of bean type since we are
expecting here a generic type anyway
When a function is created using an isolated class loader it might
want to use that class loader again for its invocations, and a lot
of tools (Spring etc.) use the context class loader for that kind
of thing if they don't have an explicit default value. So we
set the context class loader before, and unset it after, the
function invocation using a convenience wrapper.
This makes dynamic function registration (after context starts) much
easier. Also frees us from having to employ BeanFactoryPostProcessor
and other tricks to get the functions registered on startup.
This change includes caching and smarter analysis of classpaths
to limit the amount of jar walking necessary to find dependencies
when compiling. It also includes some new tests that verify
packaging of dependencies in boot style form (BOOT-INF/lib and
BOOT-INF/classes).
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
