* Add `AmqpHeaders` headers
* Add `JavaType` headers mapping to `DefaultAmqpHeaderMapper`
* Add ability to Json Transformers to add/extract `JavaType` headers
* Make `JsonToObjectTransformer#targetClass` as non-required and do fallback
to extract type from `JavaType` headers
* Add `JavaType` extraction in the `JsonObjectMapper` implementors
JIRA: https://jira.springsource.org/browse/INT-2809
INT-2809: Polishing and refactoring
* Introduce `JsonHeaders`, `AbstractJacksonJsonObjectMapper`
* Move `TestPerson` and `TestAddress` to package level
* Now `JsonToObjectTransformer` supports not only `String` payload
* Remove json headers after transformation in the `JsonToObjectTransformer`
INT-2809 Minor Polishing
INT-2809 Docs and What's New
Wrap `FileInputStream` and `FileOutputStreams` with
`BufferedInputStream`, `BufferedOutputStream` respectively.
Also use `BufferedReader`, `BufferedWriter` to wrap `FileReader`, `FileWriter`.
JIRA: https://jira.springsource.org/browse/INT-2953
Previously, these tests examined specific stack frames to
verify the handler was directly invoked by the Dispatcher.
JIRA: https://jira.springsource.org/browse/INT-3188
Add a utility method to scan the stack trace instead to
verify that the Dispatcher frame exists before any
MessagingMethodInvokerHelper frame.
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
- Close child context before parent to publish child close event to parent
- SpelRouter FB injection
- Don't pass null Method to TransactionAttributeSource.getTransactionAttribute()
When determining candidates for direct invocation, we need
to use the target of any existing proxy (such as JMX Metrics).
Copy ServiceActivatorDefaultFrameworkMethodTests to the JMX project
and adjust to work with JMX Proxies.
INT-3185: fix for AbstractSMHFBean#checkReuse
JIRA: https://jira.springsource.org/browse/INT-3185
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.
https://jira.springsource.org/browse/INT-2629
Strategy for mapping gateway methods to map method arguments
to a message.
Default strategy works as today, but pluggable using attribute
'mapper' on <gateway/>.
A custom mapper should implement InboundMessageMapper<MethodArgsHolder>
where the MethodArgsHolder contains the Method object and the argument
values.
When using a custom mapper, the mapper is entirely responsible for
creating the Message - therefore 'payload-expression' attributes
and <header/> elements are not allowed.
INT-2629 Polishing - Javadocs
INT-2629 Polishing
- Introduce MethodArgsMessageMapper - higher level API for custom mapper.
INT-2629: Polishing docs
https://jira.springsource.org/browse/INT-3069
Provide a mechanism to specify headers and payload-expression that can
be applied to all methods in the gateway.
- Headers defined as 'default' are globally applied to all gateway methods.
- Also supports 'default-payload-expression'.
- Headers defined on a specific method override the global settings.
- An `@Header` in the interface is overridden by a specific <header/> for that method (current behavior)
- An `@Header` in the interface is NOT overridden by a <default-header/>
- Add 3 new SpEL variables:
-- #methodName (synonym for #method - deprecated)
-- #methodString (a string representation of the method showing return type and arg types)
-- #methodObject (the Method object)
<int:gateway id="sampleGateway"
service-interface="org.springframework.integration.gateway.GatewayInterfaceTests.Bar"
default-request-channel="requestChannelBaz">
<int:default-header name="name" expression="#methodName"/>
<int:default-header name="string" expression="#methodString"/>
<int:default-header name="object" expression="#methodObject"/>
<int:method name="baz">
<int:header name="name" value="overrideGlobal"/>
</int:method>
</int:gateway>
INT-3069 Polishing - PR Comments
- Remove extra 'method' variables, just provide `gatewayMethod`.
- Parser improvements
- Schema now enforces default-header elements to precede method elements
- Doc polishing
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.
The general idea is to use Spring-MVC as much as possible.
* Introduce `RequestMapping`, `IntegrationRequestMappingHandlerMapping`
* Introduce XSD nested element `<request-mapping>` for HTTP Inbound Endpoints
* Introduce `inboundCommonAttributes` XSD attributeGroup for HTTP Inbound Endpoints
* Introduce `IntegrationNamespaceUtils#createExpressionDefIfAttributeDefined` & `IntegrationNamespaceUtils#createDirectChannel`
* Remove deprecated `name` attribute
* Remove `UriPathHandlerMapping` as superseded by `IntegrationRequestMappingHandlerMapping`
* Add documentation for `<request-mapping>`
- Add description to Reference Manual about `<request-mapping>`
* Add documentation to section 'What's new'
* Add additional test for `<request-mapping>`
JIRA: https://jira.springsource.org/browse/INT-2312, https://jira.springsource.org/browse/INT-2619
Additional changes:
* INT-2528 Remove deprecations in HTTP module
- JIRA: https://jira.springsource.org/browse/INT-2528
* Add Jackson 2 support for HTTP-inbound
* Using Jackson 2 HttpMessageConverter if Jackson 2 is available in classpath
* Make `RequestMapping` public
* Introduce `HttpContextUtils` and move `HANDLER_MAPPING_BEAN_NAME` to it
* Revert and deprecate public API
* Improve JavaDocs
* Improve Reference Manual
Thanks also to Biju Kunjummen for his incorporated commit.
* Add to `LongRunningIntegrationTest` ability to read `System.properties`
Note, ENV property 'RUN_LONG_INTEGRATION_TESTS' has a preference in case of value `true`
* Add Gradle task `testAll`
* Upgrade to Gradle 1.7
* Improve build performance by adding 'inputs'/'outputs' to some tasks
JIRA: https://jira.springsource.org/browse/INT-3155
Polishing
Remove inputs/outputs.
Polish RouterConcurrencyTest.
Use the Spring Framework stylesheet for javadocs.
Fix 3 missing package-info files.
(Aside: remove cache-sessions from 2 @Ignored test case configuration files).
* Add <spel-property-accessors> to configure a list of beans
that implement `org.springframework.expression.PropertyAccessor`
* Add `SpelPropertyAccessorRegistrar` to manage a list of PropertyAccessors
for Integration infrastructure
* Refactoring for `SpelFunctionRegistrar` and `IntegrationEvaluationContextFactoryBean`
to fix the issue when there is no `SpelFunctionRegistrar`(`SpelPropertyAccessorRegistrar`)
in the child AC, but there is one in the parent.
Previously the inheritance did't work for that reason.
* Now parent/child logic moved to `IntegrationEvaluationContextFactoryBean`
* Add documentation
JIRA: https://jira.springsource.org/browse/INT-3133
INT-3133: Rebasing, polishing and documentation
INT-3133: PropertyAccessors override support
* `@Ignore` `SOLingerTests#finReceivedNioLinger()` test
INT-3133: Change JavaDoc link to 3.0.0.RC1
Polishing
- Remove duplicate check - last bean def wins
- Doc Polishing
* Add XSD attributeGroup `smartLifeCycleAttributeGroup`
* Use it for all adapters tags
* Refactoring `AbstractChannelAdapterParser` hierarchy
* Refactoring some `MessageHandler`'s that should not have `autoStartup` & `phase`.
It is the responsibility of `AbstrctEndpoint`
* Polishing some tests according new logic
JIRA: https://jira.springsource.org/browse/INT-2998
INT-2998: Polishing
Polishing
- Reformat schemas where indentation changed
- Add SLC to the UDP inbound adapter
Previously, `RequestHandlerRetryAdvice` wrapped a Handler's (business) Exceptions in a
`MessagingException` on each retry within `RetryCallback#doWithRetry`
and before `RetryPolicy#canRetry`.
It made useless some retry framework out-of-the-box features like `BinaryExceptionClassifier`
* Push wrapping to `MessagingException` after `retryTemplate#execute`
* Polishing `ErrorMessageSendingRecoverer` regarding new logic
* Add `retryableExceptions` test
You can now properly specify Business exceptions with the retry policy to
perform conditional retry.
JIRA: https://jira.springsource.org/browse/INT-2943
Polishing
Only wrap Throwable in ThrowableHolderException if the Throwable
is not an Exception.
INT-2943: Polishing ErrorMessageSendingRecoverer
* Add `<script>` and `<expression>` to `<int:inbound-channel-adapter>`
* Refactoring for `DefaultInboundChannelAdapterParser`
* Introduce `ScriptExecutingMessageSource` to allow scripts' `MessageProcessor`
implementations work as a source for polling endpoint
JIRA: https://jira.springsource.org/browse/INT-2867
INT-2867: documentation
In addition the tests for Lifecycle attributes
Polishing
* #jsonPath function is registered automatically if the library is on the classpath
* Add otional dependency on `com.jayway.jsonpath:json-path` artifact
* Add `JsonPathUtils` class as a wrapper around `JsonPath`
* Add `#jsonPath` tests for: `<transformer>`, `<filter>`, `<splitter>`, `<router>`
JIRA: https://jira.springsource.org/browse/INT-3139
INT-3139: Further improvements
* Remove `SpelFunctionRegistrar`
* Introduce `SpelFunctionFactoryBean`
INT-3139: Polishing
Previously, provided `MessageProcessor` to create a `MessageHandler`
for endpoint was wrapped to `MethodInvokingMessageProcessor`,
e.g. `GroovyScriptExecutingMessageProcessor`.
Check the type of provided object in the constructor
of `MethodInvoking*` strategies and use it directly if it is `MessageProcessor`
JIRA: https://jira.springsource.org/browse/INT-2433
* `AbstractMappingMessageRouter#addChannelFromString` uses
`StringUtils.tokenizeToStringArray`, so it's enough to check it from test.
JIRA: https://jira.springsource.org/browse/INT-2117
Send is deemed to be successful if sent to at least this
number of subscribers (default 0).
Note: when using a task executor, if there is at least one
subscriber, a send is always good, regardless of success
or failure of invoking the handler.
Polishing - Docs - PR Comments
* add `<spel-function>` XSD element
* add `SpelFunctionParser`
* add `SpelFunctionRegistrar` to avoid introducing some confused 'Method'-bean
* add `SpelFunctionRegistrar` collaboration with `IntegrationEvaluationContextFactoryBean`
* some refactoring for `IntegrationEvaluationContextFactoryBean`
* polishing some failed tests after this change
JIRA: https://jira.springsource.org/browse/INT-1639
INT-1639: SpelFunctionParser use BeanClassLoader
INT-1639: Inherit 'functions' from parent AC
INT-1639: Document the <spel-function>
INT-1639: 'NoSuchBeanDefinitionException' fix
Polishing
Invoke ARPMH Directly (SA, Splitter etc)
If a bean referenced by a service activator etc, is already an ARPMH,
then wire it directly into the endpoint rather than wrapping it in a
MethodInvoking Handler.
Disallow the same bean being used in this way in multiple endpoints.
It would cause rewiring of outputChannel etc.
Detect such use and suggest using prototype scope.
Previously, an ARPMH used in a MethodInvokingHandler didn't work
in some cases, because the "inner" ARPMH had no output-channel
and the outer ARPMH (e.g. transformer) wouldn't get a reply and
would complain if requiresReply is set.
The general solution is to detect the ARPMH targetObject in
AbstractStandardMessageHandlerFactoryBean, invoke canBeUsedDirect()
to allow the subclass to vote - specifically it will be allowed
if the type is not also a special type understood by the subclass
and no endpoint-specific attributes are set.
To this end, remove a few default attributes from the schema to
enable detection of explicit setting of these attributes.
If these conditions pass and the method is handleRequest (either
explicitly or by omission) then wire it in and invoke the
subclass to post process the handler (set attributes).
Restructure this post processing in each subclass so that it can be invoked in
this way, or directly by the subclass when it makes a custom
handler.
Polishing - PR Comments
Mainly a little refactoring in the RouterFactoryBean to allow
the parameter in canBeUsedDirect() to be an ARPMH instead of
Object.
Plus a couple more minor changes.
Polishing tests to follow with new changes in the SPR 4.0
Polishing build.gradle to be compatible with SPR 4.0
Build passes with SPR 3.2.4 too
JIRA: https://jira.springsource.org/browse/INT-3131
Requires Jackson2
Bump Jackson2 version
Remove write support
Add String support
Polishing
Initialize objectMapper field; assert ObjectMapper is not null.
Newlines at ends of files.
Move definition of the IntegrationEvaluationContextFactoryBean
from DefaultConfiguringBeanFactoryPostProcessor to
AbstractIntegrationNamespaceHandler.
We need a separate eval contexts for each app context so that child
contexts get the correct BeanResolver.
Add Test For IECFB and Parent Context
There were several "helper" classes where the context was initialized
in the constructor, before the BeanFactory was passed in.
Generally fixed by adding the BeanFactory to the constructor args.
Other cases where the container-managed bean instantiated a helper
and never passed in the BeanFactory.
Finally, a fix to ExpressionUtils where the caller had a BeanFactory
but the BF did not contain an EvaluationContext factory bean, the
BeanResolver was not set up. This is unlikely in a Spring Integration
application, but added for completeness.
INT-3115 Add a BeanFactory to Test Cases
Change the WARN log in ExpressionUtils to a fatal exception to detect
cases where an EvaluationContext was created without a BeanFactory.
While this was generally in test cases, it also exposed some cases
in code where the context was initialized without a BF.
polishing on merge
