JIRA: https://jira.spring.io/browse/INTEXT-118
It also tests long messages without newlines to verify that the fix works for both types of long messages.
INTEXT-118: Replace regular expression split with standard substring to split message into subparts with max length.
The regular expression used earlier failed splitting messages that contained newlines correctly. (See SmesMessageSpecificationTest)
Corrected spelling in constants
Polishing
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`
