The default expression in the `DefaultFileNameGenerator`
is based on a message header which simply can be retrieved
with much faster `FunctionExpression`
* Some other code style refactoring in the `DefaultFileNameGenerator`
Fixes https://github.com/spring-projects/spring-integration/issues/3686
* Add `src/idea` with respective editor config for IntelliJ IDEA.
Must be imported into an IDE
* Add `src/eclipse` with respective editor config for Eclipse/STS
* Reformat imports in source code according a new editor config
The `GatewayProxyInstantiationPostProcessor` does nothing on the AOT phase.
Therefore, scanned and imported beans for `@MessagingGateway` are not decorated
after AOT
* Implement a `BeanRegistrationAotProcessor` in the `GatewayProxyInstantiationPostProcessor`
to `RegisteredBean.getMergedBeanDefinition()` withe respective `AnnotationGatewayProxyFactoryBean`
and its requirements for ctor arg and `targetType`
* Scan for the `@MessagingGateway` bean in the `GatewayProxyInitializationAotProcessor`
to register respective proxy hints
It looks like some of Spring project's bom added after `spring-framework-bom`
causes a mess with dependencies: it brings those SF deps which are in the
latest `mavenBom`
* Move `spring-framework-bom` to the end of the list to be sure that
its version comes properly
* Do the same for Spring Data - after Spring AMQP and Spring Kafka
The SF now understands `targetType` on a `BeanDefinition` for `FactoryBean`
* Remove `FactoryBean.OBJECT_TYPE_ATTRIBUTE` from the `GatewayParser`
* Expose `targetType` on a bean definition for an `AnnotationGatewayProxyFactoryBean`
in the `IntegrationFlowBeanPostProcessor` for DSL definitions
* Copy docs to the `$buildDir/reference` instead of `docs`
to make `asciidoctor` tasks to calculate their UP-TO-DATE key properly
* Generate `kdoc` outside the `docs` dir to not interfere with `asciidoctor`
* Downgrade Tomcat to `10.0.23` since SF-6.0.0-RC3 is not compatible yet
* Exclude `jakarta.activation` and `com.sun.mail` transitive deps to avoid
classpath conflict with Jakarta EE 10
* Fix mail module to fit to the latest mail API requirements
* Fix the last Sonar smell in the `SmbShare`
* Remove redundant dependency for `hamcrest-core` in various modules
* GH-3938: Fix HTTP XML configuration for ambiguity
Fixes https://github.com/spring-projects/spring-integration/issues/3938
The `encoding-mode` is a property of the `RestTemplate`.
Therefore, it cannot be set on the component configuration together with
an externally injected `rest-template`
Even if `HttpRequestExecutingMessageHandler` has an assertion for such
an ambiguity, the XML parser just ignores this `encoding-mode`
when it encounters the `rest-template`
* Fix `HttpAdapterParsingUtils.verifyNoRestTemplateAttributes()` to check for not allowed
attributes with a `encoding-mode` as well
* Remove a `default` from the `encoding-mode` to not cause an ambiguity in the parser
* Fix some typos in the `spring-integration-http.xsd`
* Rework `OutboundResponseTypeTests` to JUnit 5
**Cherry-pick to `5.5.x`**
* * Fix error handling for `encoding-mode` in the `HttpAdapterParsingUtils`
* Cover `encoding-mode` and `rest-template` ambiguity with a test against failing XML configuration
* * Improve error message for ambiguous attributes in the `HttpAdapterParsingUtils`
* GH-3903: Improve AOT for gateway proxy beans
Fixes https://github.com/spring-projects/spring-integration/issues/3903
* Fix `MessagingGatewayRegistrar` to set a `targetType` on the bean definition
instead of `FactoryBean.OBJECT_TYPE_ATTRIBUTE`
* Rework `GatewayProxyBeanRegistrationAotProcessor` to the
`GatewayProxyInitializationAotProcessor implements BeanFactoryInitializationAotProcessor`
to avoid custom code generation
* Remove tests which rely on the `FactoryBean.OBJECT_TYPE_ATTRIBUTE`
* * Add `setBeanClass(GatewayProxyFactoryBean.class)` to satisfy Spring container expectations
* * Rework `GatewayProxyInitializationAotProcessor` to deal with generics
we are exposing now on the `ProxyFactoryBean`
To avoid duplication for scanning register a `IntegrationComponentScanRegistrar`
as a bean by itself and check for its presence before scanning
* Exclude this bean definition from the AOT since its logic has already passed on AOT generation
and we don't need this bean at runtime any more
* Some code style improvement for SMB classes
* Make an `SmbSessionTests` based on the `SmbTestSupport` for faster execution, but not blocking on fake URL connection attempt
* Remove `AbstractMqttMessageDrivenChannelAdapter.Topic` model in favor of `LinkedHashMap` handling
* Add Java DSL for Camel module and docs
* Introduce a `LambdaRouteBuilder` option into the `CamelMessageHandler`
to easily provide the Camel route just in-place
* * Fix language in docs
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* Fix gateway proxy for generic interface in XML
Without a `FactoryBean.OBJECT_TYPE_ATTRIBUTE` the application context cannot determine a qualified
with generic an interface injection
* Set back `FactoryBean.OBJECT_TYPE_ATTRIBUTE` in the `GatewayParser`
when not in AOT mode.
Set a `targetType` when used in AOT
* * Remove unused import
* * Fix `GatewayParserTests` for new code base
* Add Java DSL for GraphQL
* GraphQl.outboundChannelAdapter() -> outboundGateway()
* * Add `private` ctor to `GraphQl`
* * Just `GraphQl.gateway()` - there is not going to be any other components
to handle GraphQL operations.
Also, the `outbound` in the name might confuse, where we, essentially, query a GraphQL data
* Fix typo in the doc
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* Add observation to inbound endpoints
* * Improve `Observation` logic in the `MessageProducerSupport` and `MessagingGatewaySupport`
* Clean up Javadocs in observation support classes
* Add test for `MessagingGatewaySupport` instrumentation into `IntegrationObservabilityZipkinTests`
* Add docs for `@EnableIntegrationManagement.observationPatterns()`
* The generated docs for metrics and spans looks OK: have both `Gateway` and `Handler` section now
* * Fix Checkstyle violations
* * Fix `IntegrationMBeanExporter` to filter out a `MessageProducer` from sources.
Marking a `MessageProducerSupport` with an `IntegrationInboundManagement`
causes it to be considered as a source for JMX.
Technically it might have a reason since it is indeed a source, but that's fully different story
* * No observation instrumentation by default
* * Fix "no observation by default" configuration logic
* GH-3926: BeanNameGenerator for @MessagingGateway
Fixes https://github.com/spring-projects/spring-integration/issues/3926
Current approach for generated bean name in the `MessagingGatewayRegistrar`
is to decapitalize simple class name, which is similar to standard `AnnotationBeanNameGenerator`
* Make logic in the `MessagingGatewayRegistrar` based on the provided `BeanNameGenerator`
* Expose an `@IntegrationComponentScan.nameGenerator()` attribute to allow to customize
default bean name generation strategy
* Introduce `IntegrationConfigUtils.annotationBeanNameGenerator()` to
take a provided `AnnotationConfigUtils.CONFIGURATION_BEAN_NAME_GENERATOR` singleton
or fallback to the `AnnotationBeanNameGenerator.INSTANCE`
* Use this utility in the `IntegrationComponentScanRegistrar` if no custom strategy is provided
in the `@IntegrationComponentScan`
* Use same util from the `GatewayParser` since there is no custom naming strategy configuration
* Some other current Java level refactoring in the `IntegrationComponentScanRegistrar`
and `MessagingGatewayRegistrar`
* * Meta-annotate `@MessagingGateway` with a `@MessageEndpoint`
* Alias `@MessageEndpoint.value()` with a `@Component.value()`
* Alias `@MessagingGateway.name()` with a `@MessageEndpoint.value()`
* * Remove unused imports
* * Replace `MessagingGatewayRegistrar` parsing logic for annotation configuration
directly by the `GatewayProxyInstantiationPostProcessor` and `AnnotationGatewayProxyFactoryBean`.
* The `MessagingGatewayRegistrar` logic has been migrated back to the `GatewayParser`,
but only with an XML-relevant parts
* Change the logic of the `IntegrationComponentScanRegistrar` to rely on a `ClassPathBeanDefinitionScanner`
and its `scan()` functionality since this is all what we need to trigger a `GatewayProxyInstantiationPostProcessor`
for scanned components
* Fix `GatewayProxyInstantiationPostProcessor` to call an `afterPropertiesSet()` as well
* Add a `value()` alias attribute for the `@MessagingGateway` to satisfy a name resolution from a `@Component`
* Replace annotation chain resolution logic by new `MessagingAnnotationUtils.resolveMergedAttribute()` API
* Use `MergedAnnotations` API in the `AnnotationGatewayProxyFactoryBean` to preserve a logic for attribute
resolution from the annotation hierarchy
* Add expression resolution for attribute values in the `AnnotationGatewayProxyFactoryBean`
* Make a `GatewayInterfaceTests.CustomBeanNameGenerator` as an `AnnotationBeanNameGenerator`
extension to satisfy the test logic expectations: no custom name if explicit is present
* Clean up some doc typos after merge conflict
The fix in this commit essentially resolves some old JIRA ticket: https://jira.spring.io/browse/INT-4558
* * Remove redundant `MessagingAnnotationUtils.resolveMergedAttribute()`
* Optimize the logic in the `AnnotationGatewayProxyFactoryBean` around
annotation attributes to plain annotation - no adaptation to maps
* GH-3923: Add @MessagingGateway @Import support
Fixes https://github.com/spring-projects/spring-integration/issues/3923
Currently, the `@MessagingGateway` interfaces can be scanned or created
explicitly as `@Bean` definition for `AnnotationGatewayProxyFactoryBean`
* Implement a `GatewayProxyBeanDefinitionPostProcessor` which is invoked
before instantiation attempt on the `BeanDefinition`
* Verify `@Import` for `@MessagingGateway` interface in the `GatewayInterfaceTests`
* Remove supplier for `GatewayProxyInstantiationPostProcessor` bean definition
Co-authored-by: Gary Russell <grussell@vmware.com>
* * Fix bean definition signature
Co-authored-by: Gary Russell <grussell@vmware.com>
* Fix double start for `AbstractEndpoint`
When we use POJO methods in the `IntegrationFlowAdapter`,
the `IntegrationFlowAdapter` is set as a `target` for the `MessagingMethodInvokerHelper`.
When endpoint is started by the application context, such a `start()` is propagated
down to the `MessagingMethodInvokerHelper`.
And in our case back into an `IntegrationFlowAdapter` instance.
This one, in turn, starts its `IntegrationFlow` internally which leads to the
start of the mentioned endpoint in the beginning.
Therefore, we cause a recursive `start()` call on this endpoint from itself.
The `running` flag is set when we are already done with the `doStart()` logic.
Therefore a recursive `start()` call leads to two concurrent polling tasks
in the `AbstractPollingEndpoint`.
* Check also for the `active` flag in the `AbstractEndpoint.start()`
and reset it in case of exception in the `doStart()`
**Cherry-pick to `5.5.x`**
* * Change assert for message timestamps to `isCloseTo()` with percentage
* * Change `catch` in the `AbstractEndpoint.start()` to `RuntimeException`:
the `doStart()` cannot throw unchecked exceptions by definition
* * Fix imports in `AbstractEndpoint`
* Add generic arg to the `GatewayProxyFactoryBean`
Related to https://github.com/spring-projects/spring-integration/issues/3923
When gateway proxy is declared manually, a `GatewayProxyFactoryBean` is used as a `@Bean`.
In this case the info about target interface is not available on a `BeanDefinition`,
unlike with a programmatic registration via `MessagingGatewayRegistrar`.
* Expose `<T>` on a `GatewayProxyFactoryBean` to make end-user to specify the type
this gateway is going to be based on.
This allows Spring container to determine the type of the `FactoryBean` bean definition
properly
* Migrate a programmatic bean definition registration from the
`FactoryBean.OBJECT_TYPE_ATTRIBUTE` to the `targetType` property
of the `BeanDefinition` based on a `ResolvableType.forClassWithGenerics()`
to simulate generic arg for the application context
* Remove `ComponentsRegistration` from the `GatewayProxySpec` since it us out of use
* Fix affected tests for newly added generic arg on the `GatewayProxyFactoryBean`
* Fix another typo in gateway.adoc
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* GH-3920: Support @Primary on @MessagingGateway
Fixes https://github.com/spring-projects/spring-integration/issues/3920
Any Spring `@Component` can also be marked with a `@Primary`.
The `@MessagingGateway` for proxying interfaces has no difference with
a standard `@Component` definition
* Modify `MessagingGatewayRegistrar` to obtain a `@Primary` marked
from the `importingClassMetadata` and pass it to the target `BeanDefinition`
* Verify the `@Primary` effect in the `GatewayInterfaceTests`
* Document this improvement
* * Fix Checkstyle violations
* Remove the `cassandra.yaml` from test resources since it does not
have any effect on the clients.
Use `datastax-java-driver.basic.request.timeout` system property instead
with `10 seconds` value to allow Cassandra client to wait for query results
a little more than 2 seconds
* Expose just an IP address for contact endpoint avoiding overhead
with attempts to connect to all addresses returned by `localhost` resolution
* Bring back `log4j-slf4j-impl` dependency since it is required for other libs
It is wrong to try to load an application context before test class in the `TestExecutionListener`
* Change `beforeTestClass()` phase for the `SpringIntegrationTestExecutionListener` to
the `prepareTestInstance()` when other `@BeforeAll` are already executed
**Cherry-pick to 5.5.x**
* Removed overridden `getMethodValue()` in the `CookieTests` which is removed from SF already
* Re-enable JDBC tests related to complex named params because of the fix in SF
* `--add-opens` for Tomcat warnings
* Upgrade to `log4j-slf4j2-impl`
* Add `cassandra.yaml` resource with increased timeouts to wait more in busy environment from Cassandra cluster
The `AbstractMethodAnnotationPostProcessor` makes a decision to use a `MessageHandler`
bean definition as is without wrapping by the type of `MessageHandler`.
There are some of them can be configured via `AbstractSimpleMessageHandlerFactoryBean`,
e.g. an `AggregatorFactoryBean`
* Check for the `AbstractSimpleMessageHandlerFactoryBean` to return as is
* Widen the replying producer by the `AbstractMessageProducingHandler` type
* Add an `AggregatorFactoryBean` with a `@ServiceActivator` configuration to test coverage
