Fixes https://github.com/spring-projects/spring-integration-samples/issues/242
Since `jasypt` is not compatible with Spring Security and recommendation
is to use BCrypt or NO-OP instead, remove its dependency and appropriate
bean definitions in favor of NO-OP password encoding.
The purpose of this `http-rest` application is out of Spring Security
encoding capabilities
Spring Boot now doesn't allow by default to override beans in the
application context
* Add `spring.main.allow-bean-definition-overriding=true` to the
test class definition to reflect the purpose of the downstream
configurations
* Fix TCP tests to use OS-selected port
https://build.spring.io/browse/INTSAMPLES-NIGHTLY-2413
Modify all the `tcpclientserver` tests to rely on the OS-selected port,
in other words set `0` to the server port and get the real port for the
client when server is listening
* * Upgrade to Gradle-4.6
* Fix Travis config do not perform assemble task
https://build.spring.io/browse/INTSAMPLES-NIGHTLY-2398/
* Remove `FileExistsMode.APPEND_NO_FLUSH` from the app.
It's not reliable for unit testing: keeps resources opened and cause
false positive assertions but at the same time no any interactions with
mock `session`
* Clean up test directories before and after tests
https://build.spring.io/browse/INTSAMPLES-NIGHTLY-JOB1-2397
To avoid race conditions with the test data and auto-started channel
adapter, it would be better to have channel adapter not started in the
beginning and prepare test data and only after that start it manually.
The race condition is when we have old data in the directory to poll
https://build.spring.io/browse/INTSAMPLES-NIGHTLY-2342
The `TcpClientServerDemoTest.testMultiPlex()` relies on the
`HashSet.size()` for assertion meanwhile that property is not `volatile`.
Since we change the state of the `HashSet` from other threads
the non-`volatile` property is not reliable source of information.
* Change the test-case to use `LinkedBlockingQueue` instead of `HashSet`
which uses `AtomicInteger` to track its `size`
https://build.spring.io/browse/INTSAMPLES-NIGHTLY-2256
The `AggregatorDemoTest` fails sporadically with no second part from
reply.
That might be as a result of the cached consumers in the
`CachingConnectionFactory`, so several `<int-jms:inbound-gateway>`
for the topic using the same connectionFactory essentially end up
using the same consumer sequentially.
And Broker considers them as a single consumer, therefore only one
message is sent.
