JIRA: https://jira.spring.io/browse/INT-3458
* Change Spring AMQP to `1.3.5.RELEASE`
* `HttpRequestHandlingEndpointSupport`: remove `MappingJacksonHttpMessageConverter` registration
* `IntegrationRequestMappingHandlerMapping`: add 'fake' `name()` attribute to the inline `RequestMapping` annotation
* `StoredProcJmxManagedBeanTests`: remove `context.stop();` code, Since `MBeanExporter` deregister MBeans on `stop()` now
* `StoredProcPollingChannelAdapterParserTests`: change deprecated `ParameterizedSingleColumnRowMapper` to the `SingleColumnRowMapper`
* `Jms`: comment out the reflection code to check the value for the `recoveryInterval`, because it is removed already in favor of `backOff`
* `NotificationListeningMessageProducer`: move the start-up listener registration to the `onApplicationEvent`,
because `MBeanExporter` moved `registerBeans()` to the `start()` now.
The same `phase` might cause the issue, that MBeans aren't registered yet for `NotificationListeningMessageProducer`
* `JpaOutboundGatewayTests`: change `@TransactionConfiguration` to the `@Transactional`. Don't know why the first doesn't work now.
**Cherry-pick to 4.0.x**
INT-3458: Addressing PR comments
`NotificationListeningMessageProducer`: defer listener registration until `onApplicationEvent()`
JIRA: https://jira.spring.io/browse/INT-2738
Add a `getComponentType()` method for all handlers,
message producers, and message sources that implement
`NamedComponent` (see `SPCA.getComponentType()`).
Add rome as an optional dependency - STS complained
because AtomFeedHttpMessageConverter has a dependency
on it.
This is still a work in process.
There are a bunch of TODOs in classes
that are not managed by Spring and so
need to have the MessageBuilderFactory
injected.
But I am looking for feedback on the
approach.
INT-3309 Resolve TODOs
Provide access to the MessageBuilderFactory in all classes.
INT-3309 Polishing + Tests
* Fallback to 'fromMessage()' if mutating and inbound message is not MutableMessage
* Add 'alwaysMutate' boolean to MutableMessageBuilderFactory - coerces 'fromMessage' calls to 'mutateMessage'
* Add tests
INT-3309 Polishing; PR Comments
Also add tests to parent/child contexts where the parent has the
default message builder and the child has a mutable message builder.
INT-3309 More Polish; PR Comments
Also fix removeHeader in MMB.
JIRA: https://jira.springsource.org/browse/INT-3295
Instead of invoking the conversion service directly, do it
via a MessageConverter (DefaultDatatypeChannelMessageConverter).
That way, users can override the MessageConverter; for example,
XD wants to look at the content-type header during the conversion
process (and update the content-type).
INT-3295 Polishing
PR Comments.
JIRA: https://jira.springsource.org/browse/INT-3286
Introduce `@EnableMessageHistory` and `MessageHistoryRegistrar`.
Refactoring for `MessageHistoryParser` to use `MessageHistoryRegistrar` to follow with DRY
Add test for `@EnableMessageHistory`
INT-3286: Polishing
INT-3286: Enable several MHs with the same value
Previously the Framework allowed only one `<message-history>`
independent of their `tracked-components`.
With introduction of `@EnableMessageHistory` and `MessageHistoryRegistrar`
the `MessageHistoryConfigurer` is improved to allow
several `<message-history>` or `@EnableMessageHistory`
with the same set of `componentNamePatterns`.
INT-3286 Polishing + JMX + Docs
* Allows setComponentNamePatterns and/or setComponentNamePatternsSet to
be used as long as the settings are consistent.
* Handle the case where the `MHC` was configured as a bean (no managed set exists)
* Add support for changing the component name patterns over JMX + test case
* Docs
INT-3286 More Polishing
* Change bean name to `messageHistoryConfigurer`
* Move constant to `ICU`
* Export the MBean by the `IMBE`
JIRA: https://jira.springsource.org/browse/INT-3284
* Introduce `IntegrationConfigurationBeanFactoryPostProcessor`, `IntegrationConfigurationInitializer`
* Apply `IntegrationConfigurationInitializer` and 'spring.factories' for HTTP and Security modules
INT-3284: Address PR's comments
JIRA: https://jira.springsource.org/browse/INT-3287
* Fix package tangle (INT-3287)
* Apply `IntegrationConfigurationInitializer` for `MBeanExporterHelper`
* Previously, there was a separate `ChannelSecurityInterceptorBeanPostProcessor`
for each `ChannelSecurityInterceptor` whereas now, there is one `ChannelSecurityInterceptorBeanPostProcessor`
that processes all interceptors
INT-3284 Refactoring around config package tangle
Links to classes moved to `spring-messaging`.
Also `MessageHeaders` was inadvertently added back in by the
last merge.
JIRA: https://jira.springsource.org/browse/INT-3189
__NOTE: Merge to 4.0.0-WIP, not master__
Allow customization of the generated ObjectName for the
Integration components.
JIRA: https://jira.springsource.org/browse/INT-2628
INT-2628 Polishing
- Address PR comments
- Rename `naming-strategy` to `object-naming-strategy` for consistency with `object-name-static-properties`
Previously, methods with primitive parameters were not matched
with primitive wrapper objects.
Check, if the argument is a primitive wrapper, that the paramer type
can be the equivalent primitive.
Add test case.
INT-3182 Polishing - PR Comments
Extract PrimitiveWrapper->Primitive map to ClassUtils.
JIRA: https://jira.springsource.org/browse/INT-3182
When a simple MessageHandler is referenced from a
`<service-activator/>`, it is wrapped in an anonymous
AbstractReplyProducingMessageHandler to facilitate proper handling of
the `<request-handler-advice-chain/>` and so that normal
'produced no reply` messages are logged.
Previously, this caused 2 MBeans to be exposed, one for tha actual
handler; one for the wrapper.
This added more stack frames between the dispatcher and the
handler (because 2 sets of statistics were captured).
The root cause was that the MBean exporter was not aware of the
relationship between these objects.
https://jira.springsource.org/browse/INT-3186
Add code to the IntegrationMBeanExporter to suppress adding
metrics to the wrapper.
This involves detecting that it is a wrapper and not exposing
it as an MBean and, when matching handlers with endpoints,
checking that the wrapped handler is the actual handler for the endpoint.
Update test to reflect the reduced number of stack frames between
the dispatcher and handler.
Also add tests to verify the detection of multiple references to
the same ARPMH.
INT-3186: `IntegrationMBeanExporter` optimization
https://jira.springsource.org/browse/INT-2961
onInit() relied on subclasses calling super.onInit() to apply the
advice chain and add the BeanFactory to the MessagingTemplate.
At least one extension (smpp) failed to do this, disabling these features.
Make onInit() final and call doInit() for subclass initialization (no-op in ARPMH).
INT-2961 Polishing
- do not increase visibility of doInit in subclasses.
- remove final modifiers from doInit so user subclasses can participate in initialization if needed.
This commit updates Spring Integration to depend upon Spring 4, making
use of the message types that have moved from Spring Integration into
Spring's new spring-messaging module.
The default message converter no longer supports conversion of a
message that is null, throwing an IllegalArgumentException if an
attempt is made to convert null. Furthermore, GenericMessagingTemplate
does not support sending null, again throwing an
IllegalArgumentException. Previously, MessagingTemplate had no-oped an
attempt to send null.
ConcurrentAggregatorTests and AggregatorTests both had a single test
that was specifically testing the behaviour of an aggregator that
returns null for its message. These tests have been removed.
CorrelatingMessageHandlerTests have been updated to specify some
additional behaviour for its mocks so that null messages are not
returned.
These are the only functional changes that have been made. All other
changes are simply for moving to the repackaged and/or renamed types.
In the move to being part of core Spring, a number of constants and
header accessor methods have moved from MessageHeaders to
MessageHeaderAccessor. This commit continues this pattern for
the enterprise integration headers that are specific to Spring
Integration. A new class, EiMessageHeaderAccessor, has been created.
This class provides constants and methods for working with SI-specific
headers. The main code and tests have been updated to use this new
class.
Add an MBeanTreePollingMessageSource that produces a graph of simple objects representing the JMX tree (INT-3124).
The DefaultMBeanObjectConverter converts MBean objects into a graph of Lists, Maps and arrays or primitives.
Formatting tidy, per feedback.
Feedback incorporated: split setter/attributes, more tests, inner bean constructor, logging changes.
Overloaded setter methods with different parameter types are now named separately, the endpoint attributes reflect this and tests are added to reflect this.
An inner bean can be supplied to provide an alternative MBeanObjectConverter.
Log a warning instead of a more destructive UnsupportedOperationException where there's incomplete parsing in the DefaultMBeanObjectConverter and add a trace level for exception debugging.
Minor test change and doc/reference update
Added attribute filter interface as suggested. Three implementations are provided 'all', 'named only' and 'not named'
actually add notnamedfield filter (doh).
Polishing
Some handlers get a componentName, but not a beanName. For example
the TransformerFactoryBean may create a Transformer that's not
a bean, to wrap a POJO, or expression. The AbstractSimpleMessageHandlerFactoryBean
transfers the component name to the transformer but it has a null
beanName. It would not be appropriate for the FB to change the beanName.
The IntegrationMBeanExporter's fallback, when it can't find the handler
as part of a stand-alone endpoint, is to use the handler's toString().
IntegrationObjectSupport (IOS) toString delegates to Object.toString()
if there is no beanName.
IOS's getComponentName() falls back to the beanName if there is no
component name.
Change the IMBE to use the componentName as the first fallback and,
if null, fallback to the current fallback.
One side effect is that handlers that do have a bean name
will no longer have '.handler' at the end of their name; but this
is not really an issue because the MBean is designated as a
handler anyway (via the bean component of the ObjectName).
However, identifying chain components is new in 3.0 so this is
not really a breaking change.
* Add `requires-reply` attribute for all adapters outbound gateways as `true` by default
* WS-outbound-gateway is still without it, because it has its own specific attribute `ignore-empty-responses`
* Make `requires-reply` as `false` by default for `jdbc:stored-proc-outbound-gateway` inasmuch as `jdbc:stored-proc-outbound-adapter`
doesn't have ability to configure `returning-resultset`
* add parser tests for `requires-reply`
JIRA: https://jira.springsource.org/browse/INT-2822
INT-2822 'requires-reply' for ws:outbound-gateway
Default false.
INT-2822: Polishing after rebase
INT-2822: deprecate 'ignore-empty-responses'
* Add 'requires-reply' section into What's New
INT-2822: remove 'ignore-empty-responses' from RM
INT-2822: Polishing after rebase
INT-2822: Rebased and polished
INT-2822: Rebased and polished
Add WARN within deprecated `AbstractWebServiceOutboundGateway#setIgnoreEmptyResponses`
Revert 'ignore-empty-responses'; Doc Polishing
Spring 3.2.3 registers MBean operations with parameter names
instead of the JVM default p1, p2 etc based on parameter position
in the method signature.
Since the OperationInvokingMessageHandler matched the supplied
arguments using the p1, p2 etc names, this prevented the control
bus from finding the target method.
Fall back to the old naming scheme based on parameter position
if a matching parameter is not found.
Add a test using a Map payload to supply the named arguments (p1, p2).
Add an ignored test that tests using named arguments (key, channelName).
Test with 3.1.4; remove Ignore and test with 3.2.3.
TODO: remove the Ignore annotation when SF 3.2.3 is the minimum.
INT-2964 - JavaDoc: <emphasis> should be <em>
INT-2964 - JavaDoc: <p/> should be <p>
INT-2964 - JavaDoc polishing
* <li></li> should be wrapped in <ul></ul>
* wrap code snippets in {@code myCode()}
* change <code>false</false> to <code>false</code>
INT-2964 - Polish - Fix more JavaDoc errors
* Mockito-all dependency causes JavaDoc error. Change dependency to Mockito-Core.
Permit the specification of an ObjectName pattern in
NotificationListeningMessageProducer.
Permit a collection of ObjectNames (patterns).
INT-2487 Polishing
Use varargs and a SpEL Reference instead of 2 setters.
Log an error if no MBeans matching pattern(s).
INT-2487 Polishing: PR Review Comments
Add patterns to ERROR log when no MBean(s) found.
Add doc to schema and reference.
Add general capability to advise just the handleRequestMessage
part of an AbstractReplyProducingMessageHandler.
This is to advise just the immediate operation, and not the
entire downstream flow.
Uses include:
* outbound gateway post processing
* adding retry behavior using spring-retry
* adding circuit breaker functionality
Initial commit for review.
Also need to advise simple message handlers (such as file
etc) to allow them to post-process file operations
with payload.delete(), payload.renameTo(...) etc.
INT-2250 Add Circuit Breaker Advice
INT-343 Add Retry Advice
Stateless and Stateful retry using spring-retry. Stateless
means the RetryTemplate performs the retries internally.
Stateful means the exception is thrown (e.g. to JMS container)
and the retry state is maintained by spring-retry.
INT-2215, INT-343, INT-2250 Refactoring
Factor out common abstract Advice class.
INT-2214 Catch Evaluation Expression Exceptions
If an onSuccess expression evaluation fails, add an
option so the user can decide whether such an exception is
caught, or propagated to the caller.
INT-2214 etc PR Review Polishing
INT-2214 etc Namespace Core, File, FTP
Add <request-handler-advice-chain/> to outbound endpoints.
INT-2214 etc. More Namespace Support
amqp, event, gemfire, groovy, http, ip, jdbc, jms, jmx, jpa, mail, rmi, sftp, twitter, ws, xmpp
INT-2214 etc Polishing
PR Review
INT-2214 etc Polishing
Don't catch Throwable.
Move Advice classes to handler.advice package.
JMX endpoints need a reference to an MBeanServer. The MBeanServer
is a sub-interface of MBeanServerConnection.
When connecting to a remote MBeanServer, the server is an
instanceof MBeanServerConnection, not MBeanServer.
Change the Endpoints to get a reference to an MBeanServerConnection.
Add IOException catch clauses where necessary.
* Add beginShutdown() and endShutdown() to OrderlyShutdownCapable
* JMS/AMQP stop listener containers
* TCP (server side)
** after beginShutdown() disallow new connections, drop (log) new messages
** after endShutdown() close server socket
* HTTP (server side)
** after beginShutdown() disallow any new requests (503 Service Unavailable)
* Docbook updates
** What's new section
** Orderly Shutdown section.
Initial commit - @ManagedOperation on IMBE
- can be invoked via JMX, <control-bus/>, or getting a reference to
the IMBE from the application context.
INT-2485 Updates After Review Comments (JIRA)
* Shutdown Schedulers first, and wait for them
* Add a force parameter, which overrides thread pool shutdown options
* Shutdown Sources/Channels after all thread pools have stopped
* Mark other components as OrderlyShutdownCapable (e.g. JMS/AMQP Listener containers) and shut them down first
* Wait for remaining time to allow for quiescence
Also
* remove TimeUnit parameter (not JMX-friendly); time limit is now always milliseconds
* If thread pools don't stop in time limit, force them down.
INT-2485 Handle Self-Destruction
Add shutdown-executor to IMBE.
When the shutdown was called on a Spring-Managed thread, the shutdown
was not clean because we timed out waiting for the current thread to
terminate. After that, we force terminated other components.
Now, by providing a dedicated Executor for the shutdown process, it
is used for the shutdown instead of the current thread. This Executor
is *not* shutdown.
It is not necessary to provide an Executor if the stopActiveComponents()
method is called on some other thread that is not involved in the
shutdown.
Also adds executor name to logs, when available.
INT-2485 Polishing
Fix MBean object name collision when running all tests.
INT-2485 Enable TCP Shutdown
Make TCP connection factories 'OrderlyShutdownCapable' so
they are stopped before schedulers/executors in order for
them to release any executor threads they are holding.
INT-2485 Polishing
Didn't need DirectFieldAccessor - scheduler and executor have
an accessor for the native ExecutorService.
Copyrights
INT-2485 Polishing
schemaLocation version.
INT-2485 PR Review Polishing
Channel creation logic for channels that are not explicitly defined but identified via an 'input-channel' attribute on the corresponding endpoint is now done by ChannelInitializer - an InitializingBean implementation.
This bean plays a role of pre-instantiator since it is instantiated and initialized as the very first bean of all SI beans using AbstractIntegrationNamespaceHandler
INT-2434-v3 polishing
INT-2434-v3 polishing, changed ChannelCreatingFactoryBean from BeanFactoryPostProcessor to BeanFactoryAware
INT-2434 polishing
fix the test
changed the default name of the CHANNEL_CREATOR_BEAN_NAME to a simple name
added additional test
changed ChannelCreatingFactoryBean from FactoryBean to InitializingBean and renamed it to ChannelInitializer
INT-2434 added test validating how automatic channel creation can be disabled
INT-2434 polished based on the latest PR comments
INT-2434-v3 polishing based on comments and discussions with @markfisher and @garyrussell. Added support for disabling aut-creatioin of channels
INT-2434-v3 polished based on @garyrussell last comments
INT-2434-v3 final polishing
The AbstractChannelAdapterParser creates an implicit DirectChannel
if the adapter has no 'channel' attribute.
The Event, TCP, and UDP channel adapter parsers did not bind
this channel to the adapter and AC initialization failed with
'outputChannel is required'.
Further, the event schema marked the channel as being 'required',
precluding this feature.
INT-2407 Remove Channel use="required"
Parsers automatically generate the channel when none is provided.
- JMX
- JDBC
- SFTP
- Redis
- Feed
- XMPP
- Mail
- FTP
- HTTP
If multiple application contexts exist in the same JVM, where
managed beans exist with the same name, InstanceAlreadyExistsExceptions
could result.
1. Change int-jmx MBean exporter parser to ensure the exporter itself
has a unique name within the JVM.
2. When the IMBE exports Integration components for monitoring, where
the component itself is already an MBean, add domain and object name
static properties configured in the MBean exporter.
3. Add tests to load the same ac a second time to ensure no naming
conflicts arise.
