Ensured that in the event the binding specific error channel is an instance of the DirectChannel, no more subscribers are addeed after the initial one
Added tests
Resolves#1510Resolves#1514
Several of the Asciidoc headings were one level too deep inside the
"Error Handling" section. As a result, they rendered incorrectly.
It's clear from the introductory paragraph of the "Error Handling"
section that "Application Error Handling" and "System Error Handling"
should be siblings. But because the nesting level was too deep, they
were being rendered like this:
- Error Handling
- Application Error Handling
- System Error Handling
Fixing the nesting level should resolve the problem.
Resolves#1500
Because of a re-bind of properties that is needed to address the way
default properties are handled (See the prvious commit), camelCase
binding is broken. Fixing this issue with camelCase binding.
Resolves#1495
* Both core and extended consumer/producer properties must behave in a consistent manner.
* Default binding properties must apply onto the individual binding properties that are NOT set
* Individual binding properties that ARE set must take precedence over the default binding properties (treated as an override)
* Add unit test to verify
Resolves#1494Resolves#1473
- Update IntegrationFlowFunctionSupport with the necessary changes to bind function, consumer, supplier
- Add changes to AbstractMessageChannelBinder to add appropriate input/output message channel configuration to accommodate
function support
- Upate tests
Resolves#1480Resolves#1475
Test demonstrating the issue
Revert extra diffs
Updated changes
If we repeatedly call String#replaceAll, we internally repeatedly call the regular expression pattern compilation every time as following:
```java
public String replaceAll(String regex, String replacement) {
return Pattern.compile(regex).matcher(this).replaceAll(replacement);
}
```
The modifications are to keep the compiled pattern.
Therefore, compiling a relatively expensive regular expression pattern does not have to be done every time.
Resolves#1486
Currenlty, we only support default properties for core producer/consumer (spring.cloud.stream.default.producer|consumer...).
These changes add support for configuring default properties for extended producer and consumer properties.
For example, if the binder type is foo, then this allows the applications to configure default properties across
multiple producer or consumer bindings in the form of spring.cloud.stream.foo.default.producer|consumer.property.
The default prefixes for the extended properties are dictated by the respective binder implementations.
Resolves#1360
Manual merging for Map in MergableProperties
Handling values with defaults in extended producer/consumer properties
Removed BinderFunctionSupport in favor of private method (at least for now)
Removed 'context.getBean()` from IntegrationFlowFunctionSupport in favor of propper DI
Resolves#1465
Move IntegrationFlowFunctionSupport injection to AbstractBinder
Add function support in TestSupportBinder and fix *FunctionsSupportTests
Use BeanPostProcessor and revert TestSupportBinder
Clean up
Set errorChannel in afterPropertiesSet
Refactor IntegrationFlowFunctionSupportWiring
Close context
Revert context.close()
