JIRA: https://jira.spring.io/browse/INTEXT-149
Some refactorings are done.
Polishing
* Add `IllegalStateException` for wrong `distributedObject`
* Add an invalid test to attempt to write to `ILock`
JIRA: https://jira.spring.io/browse/INTEXT-150
Refactorings are committed.
Polishing:
* Add generic type to the `AbstractHazelcastEventListener` for cleaner implementors
* Remove redundant `Assert`s
* Polishing some code style
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
