* Enable ModifierOrderCheck Checkstyle rule
* Fix violations for `static` and `abstract` modifier
* Remove redundant code in the `TcpNioConnection`
* Mark `connectionFactoryName` as `@Nullable` in the `TcpConnectionSupport`
ctor and its inheritors
* Fix some smells according IDEA suggestions in the affected classes
* This should fix some Sonar smells as well
* * Fix `HeaderMapperTests`
* * Polishing `TcpConnection` code style and fix Javdocs
* Fix wrong import order in tests
* Polishing for not closed application contexts
* Use diamonds
* Use proper assertion operators
* Remove redundant classes
* Improve performance in JPA tests
* Fix typos
JIRA: https://jira.spring.io/browse/INT-4479
For better user experience expose a `RequestEntity<?>` as a root object
for evaluation context for `statusCodeExpression` execution
* INT-4517: Refactor beans in IntegrationRegistrar
JIRA: https://jira.spring.io/browse/INT-4517
The `IntegrationRegistrar` populates beans into the application context
too early and when the `allowBeanDefinitionsOverride` is disabled we
end up with the `BeanDefinitionOverrideException` just because end-user
beans are applied later.
* Move most of the bean definitions which can be overridden in the target
application from the `IntegrationRegistrar` into the
`DefaultConfiguringBeanFactoryPostProcessor`
* Revise their registration logic to be sure that some of them are
registered only once in the parent context nad others are registered
in the child context as well
* Refactor a `DslIntegrationConfigurationInitializer` do not register
an `IntegrationFlowDefinition.ReplyProducerCleaner` in the child context
one more time: it doesn't bring any local store within the current
child context
* Introduce a `NoBeansOverrideAnnotationConfigContextLoader` in tests
to ensure that in some test-cases we disallow an
`allowBeanDefinitionsOverride` as it is now in Spring Boot since it is
enabled by default in the Spring Framework
* Revernt DslIntegrationConfigurationInitializer changes
Regsiter all the required infrastructure beans in all the application
contexts to avoid class loader issue for `static` store access
JIRA: https://jira.spring.io/browse/INT-4503
Custom `ErrorHandler` can't be used if an external `RestTemplate`
is provided
* Replace `isClientSet()`` with ``!isClientSet()`` for `isTrue`
assertion in `errorHandler` method
* Replace assertion of `restTemplate` `isNull` with assertion
`!isClientSet()` `isTrue` in the `requestFactory()` method
* Add test coverage for the `errorHandler` into the `HttpDslTests`
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4436
* Fix `IntegrationRequestMappingHandlerMapping` and
`IntegrationRequestMappingHandlerMapping` to implement a
`DestructionAwareBeanPostProcessor` to allow to register and
destroy HTTP endpoints at runtime, e.g. via `IntegrationFlowContext`
with the dynamic `IntegrationFlow`s
JIRA: https://jira.spring.io/browse/INT-4390
Phase I: flow context/registration cycle
- extract interfaces
- rename implementations to `Standard...`
Phase II - dsl<->dsl.channel tangles
Move the channel specs to dsl.
Fix missing refactorings
(Not related to DSL) - rename core `event` package to `events`
- avoid collision with event module package
- fix tangle caused by `MessageGroupExpiredEvent`.
Phase III - dsl<->config.dsl
- move classes from config.dsl to dsl
(Not related to DSL) - fix many tangles caused by graph being a sub-package of support.management
- make `graph` a top-level package
(Not related to DSL) - move `IntegrationManagementConfigurer` from
`management` to `config` - tangle between core and management
* Polishing Copyrights, diamonds, some JavaDocs and What's New
JIRA: https://jira.spring.io/browse/INT-4392
JIRA: https://jira.spring.io/browse/INT-4391
JIRA: https://jira.spring.io/browse/INT-4393
Resolve class and leaf package tangles in:
- core (except DSL)
- file
- http
- move `StaticMessageHeaderAccessor` to root `integration` package
- move acknowledgment related classes to a new `acks` package
- move `MMIH` to `handler.support`, alongside argument resolvers, also `HandlerMethodArgumentResolversHolder`
- move `ErrorMessagePublisher` to `core`
- move `PatternMatchUtils` to `support.utils`
- move `MessageSourceManagement` to `support.management`
- remove direct reference to `MicrometerMetricsCapter` from `IntegrationManagementSupport`
- add new class `MetricsCaptorLoader`
- move `OperationsCallback` to inner interface in `RemoteFileOperations`
- move `HttpContextUtils` to `config`
* Simplify MetricsCaptor loading.
* Polishing
Fixes https://github.com/spring-projects/spring-integration/issues/2358
The WebFlux on the server side can deal with MVC `@Controllers` as well
without any Servlet environment.
* Enable `IntegrationGraphController` when we not only in the
Servlet environment, but also in the WebFlux
* Upgrade to SF-5.0.4 and fix WebFlux tests to meet the latest requirements
(https://jira.spring.io/browse/SPR-16337)
* Move `WEB_FLUX_PRESENT` to the `HttpContextUtils`;
deprecate it in the `WebFluxContextUtils`
* Mention WebFlux ability for the `IntegrationGraphController` in the
`graph.adoc`
* INT-4376: Upgage to Log4J 2
JIRA: https://jira.spring.io/browse/INT-4376
* Deprecate Log4J 1.x components in favor of newly added
a `Log4j2LevelAdjuster` JUnit `@Rule`
* Update all the logging configuration to Log4J 2
* Polishing after testing
* Copy data format algorithm from the Spring Web `HttpHeaders` into the
`DefaultHttpHeaderMapper`
* Fix `HttpProxyScenarioTests` for proper zoned date formatting
JIRA: https://jira.spring.io/browse/INT-4350
Spring MVC and Spring WebFlux handles `ResponseEntity` via appropriate
`ReturnValue` handlers.
This way all the headers and status code are fully up to end-user.
The body is handled by the appropriate converter/writer as before
* Add `ResponseEntity` handling to the `HttpRequestHandlingMessagingGateway`
and `WebFluxInboundEndpoint`.
The logic mostly compy/pasted from the `ResponseEntityResultHandler`
* Upgrade to SF-5.0.1, Reactor-3.1.1, some other minor upgrades
* Fix `HttpDslTests` and `WebFluxDslTests` for the latest SS compatibility
* Fix JavaDoc in the `ChannelMessageStorePreparedStatementSetter`
JIRA: https://jira.spring.io/browse/INT-4315
Move Reactive components outside of HTTP module to the new WebFlux one,
including XSD, tests and documentation
Make an appropriate polishing for the `http.adoc` with cross-link
to the `webflux.adoc`
Exclude transitive `spring-webmvc` for the `spring-integration-webflux`
JIRA: https://jira.spring.io/browse/INT-4300
* Add `ReactiveHttpInboundEndpoint` based on the WebFlux foundation
* Extract `BaseHttpInboundEndpoint` for common
HTTP Inbound Channel Adapters options
* Make `spring-webmvc` and `spring-webflux` as `optional` dependencies
to let end-user to choose
* Refactor `HttpContextUtils` to include constants
for newly added WebFlux support
* Introduce `BaseHttpInboundEndpoint.setRequestPayloadTypeClass()`
for raw `Class<?>` and modify existing `setRequestPayloadType()`
for the `ResolvableType`
* Refactor existing MVC tests and XML components parsers to use
new `setRequestPayloadTypeClass()`
* Add `MessagingGatewaySupport.sendAndReceiveMessageReactive()` to get
a reply from downstream flow reactive back-pressure manner
* Add `IntegrationHandlerResultHandler` implementation to let WebFlux
infrastructure to handle the `Mono<Void>` from the `ReactiveHttpInboundEndpoint`
properly
* Fix `JdbcLockRegistryLeaderInitiatorTests` race condition to assert
the `initiator1` is elected eventually after yielding when the `initiator2`
is stopped
* Fix JavaDocs issue in the `HttpRequestHandlingMessagingGateway`
* Move all the "hard" logic in the `MessagingGatewaySupport#doSendAndReceiveMessageReactive`
to the `Mono` chain ensuring back-pressure when `sendAndReceiveMessageReactive()` is
called not from the Reactive Stream
Add test-case to demonstrate SSE
JIRA: https://jira.spring.io/browse/INT-3625
Some polishing and optimization for the
`MessagingGatewaySupport.doSendAndReceiveMessageReactive()`
More optimization for `MessagingGatewaySupport`
* Upgrade to Reactor 3.1 M3
* Document WebFlux-based components
Minor Doc Polishing
JIRA: https://jira.spring.io/browse/INT-4309
More convenient for Java Config.
*Upgrade to Reactor 3.1 B-S, Reactor-Netty 0.7 B-S and Security 5.0 B-S.
Otherwise we are not compatible with the latest SF
JIRA: https://jira.spring.io/browse/INT-4252
To allow to provide arbitrary bean names for the intermediate components
in the `IntegrationFlow` change `ComponentsRegistration` to return
a `Map<Object, String>` instead of raw `Collection<Object>`
* Use the value from that map in the `IntegrationFlowBeanPostProcessor` as a
fallback option before walking into bean name generation
* Provide `containerId` option for the AMQP DSL components
* Revert `@AfterClass` in the `AmqpTests`
* Expose `id()` for the `JmsDestinationAccessorSpec`
* Register `ListenerContainer` and `JmsTemplate`
as bean via `ComponentRegistration` in the particular JMS Java DSL components
* Fix `Jms` factory to populate the `JmsDefaultListenerContainerSpec`
for the `messageDrivenChannelAdapter()` without class specified
* Refactor AMQP DSL Inbound components to deal with the new ContainerSpec API
* Remove `containerId()` in favor of `id()` in the ContainerSpec
Since the classes load their imports explicitly we can't use them for
classes which provides utilities to check classpath
* Move imports to fully qualified names in the target utility method
**Cherry-pick to 4.3.x**
Move `JacksonJsonUtils.isPresent` methods to separate `JacksonPresent` class
Polishing
* Rename `ReactiveConsumer` to `ReactiveStreamsConsumer`
* Rename `FluxSubscribableChannel` to `ReactiveStreamsSubscribableChannel`
* Remove the `processor` functionality from the `FluxMessageChannel`
in favor of internal `FluxSink` as it is recommended by the Project Reactor:
> Most of the time, you should try to avoid using a Processor.
They are harder to use correctly and prone to some corner cases.
* Make connectable, upstream publishers for the `FluxMessageChannel` as
bridges to the internal `sink` via `this::send`.
This way we are able to receive data from multi sources.
When the source is completed (e.g. `Mono` in case of WebFlux response),
the downstream flow isn't completed.
* Rework `MessageChannelReactiveUtils#PollableChannelPublisherAdapter`
to be based on the `Flux.create()` and `onRequest()` to poll channel for messages
* Add one more request to the `ReactiveHttpRequestExecutingMessageHandler`
to be sure that we consume different `Mono`s by the `FluxSubscribableChannel`
properly without completion
* Upgrade to the `spring-io-plugin:0.0.7.RELEASE`
Add `IntegrationConsumer` implementation to the `ReactiveStreamsConsumer`
It's difficult to subclass this mapper (e.g. to extend `toHeaders` to tweak the map)
because the factory methods for inbound and outbound mappers use private static fields
to set up the standard header mapping.
Extract that logic so that subclasses can create similar static methods and invoke the
setup code to set the standard header mapping.
Polishing: make more `DefaultHttpHeaderMapper` members available for inheritors
JIRA: https://jira.spring.io/browse/INT-4260
MPEH: Populate the `ErrorMessage.originalMessage`,
if available and not the same as the `failedMessage`.
Polishing - rename exception to `MessagingExceptionWrapper`;
make `MPEH` a subclass of `ErrorMessagePublisher`
PR Comments
Polishing - PR Comments
- as discussed last week
TODO:
- should we take the channel outside of the `AbstractMessageChannel` hierarchy?
- avoid blocking interceptors
- we would lose channel metrics though
- rename `ReactiveConsumer` ?
Polishing some missed renaming
This commit harmonizes `LockRegistry#obtain` logic in Zookeeper and JDBC
implementations with Redis implementation
by using Java 8 `ConcurrentMap#computeIfAbsent`
* Remove `synchronized (this.locks)` from the `expireUnusedOlderThan`
implementations because `iterator()` is thread-safe from `ConcurrentHashMap`
* Fix deprecation in the `IntegrationGraphControllerRegistrar`
* Revert Spring Security version to `4.2.2`, since `5.0 B-S` is broken
* Upgrade to Jackson-2.9.0 to align with SF
* Fix `ReactiveHttpRequestExecutingMessageHandler` to use latest `WebClient`
* Introduce `Supplier<URI> uriSupplier` to evaluate the `realUri` on demand.
In case of `WebClient` use `.uri(Function)` to perform `uriSupplier`
* Move `doNext()` for the `WebClientException` out of `one-way` block.
According the `RestTemplate` logic the erroneous response is handled
before returning from the `exchange()`.
Therefore both request/reply and one-way scenarios must have the same
error handling logic
* Some refactoring to the `AbstractHttpRequestExecutingMessageHandler`
and `AbstractHttpRequestExecutingMessageHandler` according a new `uriSupplier`
JIRA: https://jira.spring.io/browse/INT-4208
Since `AsyncRestTemplate` is deprecated in Spring 5.0, it doesn't make
sense to promote that feature via our new `AsyncHttpRequestExecutingMessageHandler`
component
* Rework (and rename) `AsyncHttpRequestExecutingMessageHandler` to
`ReactiveHttpRequestExecutingMessageHandler` and make it based on the
WebFlux `WebClient`
* Fix Java DSL (`ReactiveHttpMessageHandlerSpec`) and all tests according a new
logic in the `ReactiveHttpRequestExecutingMessageHandler`
* Fix XML namespace support to use new `ReactiveHttpRequestExecutingMessageHandler`
and don't expose unused options like `converters` and `request-factory`
* Fix `What's New` and `http.adoc`
* To remain with `async` mode for the `ReactiveHttpRequestExecutingMessageHandler`
behavior support fix `AbstractMessageProducingHandler` to adapt reply `Mono`
to the `SettableListenableFuture`
* Introduce new `reactive` behavior for the `AbstractMessageProducingHandler`
when `outputChannel` is `ReactiveSubscribableChannel` and perform
`.subscribeTo(Publisher)` for `Publisher` reply
* Upgrade to Spring AMQP `2.0 M3`
* Downgrade to Spring Security `4.2.2`
Address PR comments
Add async error handling to the one-way case
Minor polishing and checkstyle fix
Since `AbstractHttpRequestExecutingMessageHandler` does a copy of
the provided `uriVariableExpressions`, we lose a coupling propagating
from the ctor.
* Move `uriVariableExpressions` propagation from the ctor to the
`getComponentsToRegister()`
JIRA: https://jira.spring.io/browse/INT-4219
- Use `AdditionalAnswers.returnFirstArgument` instead of lambda to return first arg
- Enable CheckStyle `AvoidStaticImport` for tests
- Fix static import violations in tests
