JIRA: https://jira.spring.io/browse/INTEXT-111
- Remove hard coded names for bean names at the producer context parser
- Fix and update tests
- Remove the use of `BeanFactory` to get the producerConfigurations in
KakfaProducerContext and use setter to set the producerConfigurations
- Add logic to send the message from producer configuration when there
is no header specified for the topic and single producer configuration
is used.
Add tests to verify placeholder values
Fix code review comment and formatting
Polishing code style.
Add `KafkaProducerContext#theProducerConfiguration` for single `producerConfigurations` entry to avoid iterators
Since many `outbound-gateway`s are designed to always expect replies and XML configuration
specifies `requires-reply="true"` for them by default, the DSL should follow with that.
https://build.spring.io/browse/INTSAMPLES-NIGHTLY-JOB1-1189
Since `spring-integration-even` is optional dependency, the usage of `ApplicationEventListeningMessageProducer` is wrong.
Changing it to the generic `ApplicationListener` doesn't hurt for any inline components from Flow definition, when there is an interest to handle Events.
Register `ApplicationEventListeningMessageProducer` as `ApplicationListener` in the `ApplicationEventMulticaster`
Since `ApplicationContext` invokes its `registerListeners()` before the `IntegrationFlowBeanPostProcessor` does its stuff,
the `ApplicationEventListeningMessageProducer` hasn't been visible as an `ApplicationListener` bean, when it is defined from `IntegrationFlow`,
hence add a logic to register it to the `ApplicationEventMulticaster` from `IntegrationFlowBeanPostProcessor`.
JIRA: https://jira.spring.io/browse/INTEXT-80
When synchronizing to local directory, getObject was called without
ever closing the InputStream that the SDK opens causing an
"org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting
for connection" exception. To fix that, after synchronization, the
inputStream of the s3Object is closed, causing the s3 client to release
the connection.
The root of the issue is the order of bean registration in the beanFactory.
In this case the first subflows is registered correctly, but the next one has been registered after `RouterSubFlowMappingProvider`.
In this case the input `channel` of the next subflow hasn't been registered yet, hence `NPE` in the `this.router.setChannelMapping`
from `@PostConstruct` of `RouterSubFlowMappingProvider`.
Move the `RouterSubFlowMappingProvider` to end of `componentsToRegister` collection to give a chance to register all subflows before the `RouterSubFlowMappingProvider`.
Add `subFlow` support for `router`s
Move some tests to separate domain classes
Fix some component registrations
DSL: Fix `SubFlow` registration according PR discussion
* Add IO plugin
* Fix SI 4.0 <-> 4.1 compatibility by `springIoCheck` results
* Further divide for tests to separate domain classes
DSL: Add `discardFlow` to the `.filter()`
Make `.router()` `subFlow`s as `always return to the main flow`
Add `.publishSubscribeChannel()` EIP-method with `.subscriber()`
to specify subscribers as `subFlow`s
Polishing
Add support for `FunctionExpression` and apply it alongside with `expression`, where it is possible
For example:
```
.enrich(e -> e.requestChannel("enrichChannel")
.requestPayload(Message::getPayload)
.shouldClonePayload(false)
.<Map<String, String>>headerFunction("foo", m -> m.getPayload().get("name")))
```
Remove redundant functional interfaces in favor of `Function`
FunctionExpression: Add JDBC Splitter sample
Minor Polishing to FunctionExpression
FunctionExpression: JavaDocs
* Add `Function` and `Consumer` copies from Java 8
* Rework some functional interfaces to `Function` or `Consumer`
* Introduce `Channels`, `MessageHandlers`, `MessageProducers`, `MessageSources`, `MessagingGateways`
- some convenient wrappers for Namespace Factories to be used from Lambdas
* Add Lambda-methods for those new wrappers
* Provide some refactoring
* Upgrade to Boot `1.1.7`
Java DSL: Lambda_Factories
* Change all `IntegrationFlows` methods to `.from()`
* Introduce internal `Function<?, ?>` extensions for particular cases, e.g. `MessageSourcesFunction`.
Now end-user has to cast Lambda parameter to concrete type to get desired factory, e.g.:
```
return IntegrationFlows.from((MessageProducers mp) -> mp.imap("imap://user:pw@host/INBOX"))
```
* rename `.fromFixedMessageChannel` to `.from()` with additional boolean flag
* Introduce `PollerFactory` Lambda for `.poller()` EIP-method on `EndpointSpec`
* Move `Pollers` stuff to the `.core` package to fix package tangle
* Refactoring for some code style
* Fix some typos
JIRA: https://jira.spring.io/browse/INTEXT-113
Previously `router` could be configured only as last component in the `IntegrationFlow` definition.
* Remove `defaultOutputChannel` options from `AbstractRouterSpec`
* Populate `outputChannel` to the `AbstractMessageRouter.defaultOutputChannel`, when there is more EIP-methods after `.route()`
* Rename EIP-method `.recipientListRoute()` to the `.routeToRecipients()`
* Make compatibility with SI 4.1
* Tested against SF 4.1
* Introduce `MapBuilder` and its custom inheritor - `MailHeadersBuilder`
* Add `HeaderEnricherSpec.headers(MapBuilder)` and `.headers(Map)`
* Change `MailTests` to use new `Mail.headers()` and new `IntegrationFlowDefinition.enrichHeaders(MapBuilder)`
* Change `mailapi` dependency to the IO's `javax.mail`
Polishing - Add headerExpressions()
More Polishing - Add Configurer
Polishing - PR Comments
- Move MapBuilderConfigurer to superclass.
- Move PropertiesBuilderConfigurer into PropertiesBuilder.
To simplify a bit the `direct` integration flow definition, the `IntegrationFlow` Lambda is introduced.
* Extract `IntegrationFlow` functional interface with `define(IntegrationFlowDefinition<?> flow)` method.
* Rename existing `IntegrationFlow` class to the `StandardIntegrationFlow` and move it to the inner class within `IntegrationFlowBuilder`
* Extract `IntegrationFlowDefinition` superclass for the `IntegrationFlowBuilder` to be used within `IntegrationFlow` Lambda
to hide `get()` method from end-users.
* Change `IntegrationFlowBeanPostProcessor` for a new logic around `IntegrationFlow` Lambda
* Rename `MessagingProducerSpec` to the `MessageProducerSpec`
Conflicts:
spring-integration-java-dsl/src/main/java/org/springframework/integration/dsl/IntegrationFlowBuilder.java
DSL:Add SMTP Mail Server
Polishing - PR Comments
DSL: Mail: add `PropertiesConfigurer` lambda
* Move `IntegrationFlowTests` to the `flows` package to avoid cross scanning for components
* Make `MailTests` as integration test and move `Mail.outboundAdapter` to the `IntegrationFlow` `@Bean` definition
JIRA: https://jira.spring.io/browse/INTEXT-112https://jira.spring.io/browse/INTEXT-111
- Avoid using hardcoded bean names for consumer context
- Remove Integer value topic streams count, instead use string value
- This will allow placeholder values to be used for `streams` attribute
- Set `group-id` as a bean name for consumer configuration bean only if
the group id is specified explicitly. This will allow placeholder values
not being used as a bean name.
- Add test cases to verify multiple consumer configurations within the
same consumer context.
Set consumerConfigurations as propertyValue
Better handling of consumerConfigurations
- Add getConsumerConfiguration(String groupId) in KafkaConsumerContext
- Fix tests
- Add additional test case to check multi consumer contexts
Fix getConsumerConfiguration(groupId)
Polishing
**DO NOT MERGE YET**.
There is need to provide tests on the matter.
(S)FTP Tests
* Add test cases for (s)ftp components based on embedded (S)FtpServers
* Upgrade some dependencies
* Fix bug in the `IntegrationFlowBeanPostProcessor` for the registration internal (a result of `MessageSourceSpec`) as a bean in the AC
Made the corresponding API changes.
Had to update jacoco to latest (0.7.1.blah) to get the tests to work correctly on OSX Java 8
Fixed JavaDoc errors show up by the Java 8 linter. Build passes
Bringing dependencies inline with Spring 4.0.6
Updated mockito to 1.9.5
Updated Hamcrest to 1.3
Updated aws-sdk to 1.8.7
Merge branch 'master' into integration-4.0
Reformatted gradle file inline with the existing standard
Switch back to using the milestone repo
Upgrade Gradle version to 1.12
Updated the schema references to use un-versioned refs
Updated author tags and copyright dates
AWS: SI-4.0 Polishing
* Introduce `ComponentsRegistration` *marker* to extract internal components from the `IntegrationComponentSpec` to be registered as bean in the application context
* Add `ConsumerEndpointSpec#order(int order)` for the `order` of target `AbstractMessageHandler`
* Fix `AggregatorSpec` to use `DefaultAggregatingMessageGroupProcessor` by default
* Fix `IntegrationFlowBeanPostProcessor#generateBeanName` to check if `instance instanceof NamedComponent` and its `beanName` has been configured
using `IntegrationComponentSpec#id`
JIRA: https://jira.spring.io/browse/INTEXT-104
`order` attribute now honored if kafka outbound adapter is connected to a subscribable channel
unit tests and samples are updated
Polishing: use `<xsd:attributeGroup ref="integration:channelAdapterAttributes"/>` for adapter tags to cover `SmartLifecycle` options.
JIRA: https://jira.spring.io/browse/INTEXT-110
Perform the necessary API Changes (Partioner interface in Kafka is now non-genericized for Keys - concrete Object is the new type for Key)
Unit test updates for an internal Kafka class (MessageMetadata)
Updates for the samples Kafka project to use the new M2 snapshot, Spring 4.0 Messaging changes, other build related minor changes, etc.
* Upgrade to SI 4.0.3 and Boot 1.1.4
* Add `HeaderEnricherSpec#headerChannelsToString()`
* Fix `DslRecipientListRouter` according core changes
* Fix `Amqp` and `Jms` modules for the bug around "All Message creators need a BeanFactory"
using fake `new DefaultListableBeanFactory()` for `(Amqp)JmsChannelFactoryBean`
Configure the Spring IO plugin such that it's only applied when the
build is run with -PplatformVersion=<version>. This platformVersion
property is used to determine the version of the Platform that will
be used when running the springIoCheck task. The plugin can be used
by running a build as follows:
./gradlew clean springIoCheck -PplatformVersion=1.1.0.BUILD-SNAPSHOT -PJDK7_HOME=… -PJDK8_HOME=…
This will test the project on JDK7 and JDK 8 using the dependencies
defined in the latest snapshot of Spring IO Platform 1.1.0.
