Port MessageBus code from XD (XD-3244)
Fix Deprecated API Usage; Fix Imports (GH-9)
Change poms to compile using JDK7
Move transport specific test classes into binding-<transport> projects
Refactor support for channel beans
* create utility methods for registering input/output channel beans
* use utility methods within tests
Remove source-xml and rely on the @Input/@Output model entirely
* enable the component model based on @EnableModule with existing functionality
* any field annotated with Input/Output will trigger the creation and injection of a channel
* update examples and tests
* update README
In order to run a module as a child context (namespaceing the channels)
you need to have a separate ChannelBindingProperties per context,
so the condition has to have search=CURRENT. For an XD module this
was a problem because the ModuleProperties (a subclass) is needed and that
has to be added in bootstrap (i.e. in the parent context). Fixed by
registering the ModuleProperties as a singleton in the child context.
This was set on the ChannelBindingProperties bean. However, since the ModuleProperties
(which is of type ChannelBindingProperties) might have been initialized by the initializer,
the search strategy for the conditional bean needs to look at the hierarchy.
Added a TODO comment indicating this can be set to CURRENT once the initializer is removed.
No need to specify channel names (just spring.cloud.streams.name). Example
app:
@SpringBootApplication
@EnableChannelBinding
public class ExtendedApplication implements AggregateConfigurer {
@Override
public void configure(AggregateBuilder builder) {
builder
.from(TimeSource.class).as("source")
.via(LoggingTransformer.class)
.via(LoggingTransformer.class).profiles("other")
.to(LogSink.class);
}
}
Fixes gh-2
- This will make sure the options metadata classes are loaded from the jars provided in the current classloader instead of a new ParentLastURLClassLoader created in XD.
Here's how it works. User adds a bean of type ChannelLocator
qualified as @InputChannel (or @OutputChannel) and it gets
used instead of the default. The discovery version needs a
service id. What it does is invert the naming convention in
channel binding - "input" locally requires "output" remotely,
"input.topic:foo" requires "output.topic:foo" remotely etc.
/channels/taps responds to the local name as well as the "channel"
name.
Also includes a change to allow the default channel name to be
output_topic: or input_topic: (for pubsub but no particular name).
And also adds autoStartup to module properties.
