diff --git a/src/reference/docbook/aggregator.xml b/src/reference/docbook/aggregator.xml index 24d6ee7eda..d3bd3a1022 100644 --- a/src/reference/docbook/aggregator.xml +++ b/src/reference/docbook/aggregator.xml @@ -32,8 +32,8 @@ Correlation determines how messages are grouped for aggregation. In Spring Integration correlation is done by default based on the - MessageHeaders.CORRELATION_ID message - header. Messages with the same MessageHeaders.CORRELATION_ID will be grouped + IntegrationMessageHeaderAccessor.CORRELATION_ID message + header. Messages with the same IntegrationMessageHeaderAccessor.CORRELATION_ID will be grouped together. However, the correlation strategy may be customized to allow other ways of specifying how the messages should be grouped together by implementing a CorrelationStrategy (see below). @@ -42,7 +42,7 @@ ReleaseStrategy is consulted. The default release strategy for the Aggregator will release a group when all messages included in a sequence are present, based on the - MessageHeaders.SEQUENCE_SIZE header. + IntegrationMessageHeaderAccessor.SEQUENCE_SIZE header. This default strategy may be overridden by providing a reference to a custom ReleaseStrategy implementation. @@ -125,13 +125,13 @@ AbstractCorrelatingMessageHandler - and it has a default value based on the MessageHeaders.CORRELATION_ID message header: + and it has a default value based on the IntegrationMessageHeaderAccessor.CORRELATION_ID message header: @@ -454,7 +454,7 @@ then you should simply provide an implementation of the ReleaseStrate algorithm. The bean can be an implementation of the CorrelationStrategy interface or a POJO. In the latter case the correlation-strategy-method attribute must be defined as well. Optional (by default, the aggregator will use - the MessageHeaders.CORRELATION_ID header) . + the IntegrationMessageHeaderAccessor.CORRELATION_ID header) . @@ -488,7 +488,7 @@ then you should simply provide an implementation of the ReleaseStrate The bean can be an implementation of the ReleaseStrategy interface or a POJO. In the latter case the release-strategy-method attribute must be defined as well. Optional (by default, the - aggregator will use the MessageHeaders.SEQUENCE_SIZE header attribute). + aggregator will use the IntegrationMessageHeaderAccessor.SEQUENCE_SIZE header attribute). diff --git a/src/reference/docbook/amqp.xml b/src/reference/docbook/amqp.xml index 9ae0c62b84..24dbb924f6 100644 --- a/src/reference/docbook/amqp.xml +++ b/src/reference/docbook/amqp.xml @@ -640,9 +640,7 @@ public Object handle(@Payload String payload, @Header(AmqpHeaders.CHANNEL) Chann The Spring Integration AMPQ Adapters will map standard AMQP properties automatically. These properties will be copied by default to and from - Spring Integration - MessageHeaders - using the + Spring Integration MessageHeaders using the DefaultAmqpHeaderMapper. diff --git a/src/reference/docbook/configuration.xml b/src/reference/docbook/configuration.xml index 9cc9a234c1..7e378215c2 100644 --- a/src/reference/docbook/configuration.xml +++ b/src/reference/docbook/configuration.xml @@ -162,7 +162,7 @@ Specifically, the Exception will become the payload of a Spring Integration Message. That Message will then be sent to a Message Channel that is resolved in a way that is similar to the 'replyChannel' resolution. First, if the request Message being handled at the time the Exception occurred contains - an 'errorChannel' header (the header name is defined in the constant: MessageHeaders.ERROR_CHANNEL), + an 'errorChannel' header (the header name is defined in the constant: IntegrationMessageHeaderAccessor.ERROR_CHANNEL), the ErrorMessage will be sent to that channel. Otherwise, the error handler will send to a "global" channel whose bean name is "errorChannel" (this is also defined as a constant: IntegrationContextUtils.ERROR_CHANNEL_BEAN_NAME). diff --git a/src/reference/docbook/delayer.xml b/src/reference/docbook/delayer.xml index 7d2847757c..65f77d8c65 100644 --- a/src/reference/docbook/delayer.xml +++ b/src/reference/docbook/delayer.xml @@ -65,9 +65,9 @@ In the first case, the expression will evaluate to null; the second will result in something like: + Field or property 'delay' cannot be found on object of type 'org.springframework.messaging.MessageHeaders']]> So, if there is a possibility of the header being omitted, and you want to fall back to the default - delay, it is generally more efficient (and recommended) to use the + delay, it is generally more efficient (and recommended) to use the Indexer syntax instead of dot property accessor syntax, because detecting the null is faster than catching an exception. diff --git a/src/reference/docbook/jmx.xml b/src/reference/docbook/jmx.xml index d9413b2f48..375f4eae88 100644 --- a/src/reference/docbook/jmx.xml +++ b/src/reference/docbook/jmx.xml @@ -221,7 +221,7 @@ If the reply-channel attribute is not provided, the reply message will be sent to the channel that is identified - by the MessageHeaders.REPLY_CHANNEL + by the IntegrationMessageHeaderAccessor.REPLY_CHANNEL header. That header is typically auto-created by the entry point into a message flow, such as any Gateway component. However, if the message flow was started by manually creating a diff --git a/src/reference/docbook/message.xml b/src/reference/docbook/message.xml index 88fd49ae56..d109ccc7ba 100644 --- a/src/reference/docbook/message.xml +++ b/src/reference/docbook/message.xml @@ -80,10 +80,6 @@ TIMESTAMP java.lang.Long - - CORRELATION_ID - java.lang.Object - REPLY_CHANNEL java.lang.Object (can be a String or MessageChannel) @@ -92,22 +88,6 @@ ERROR_CHANNEL java.lang.Object (can be a String or MessageChannel) - - SEQUENCE_NUMBER - java.lang.Integer - - - SEQUENCE_SIZE - java.lang.Integer - - - EXPIRATION_DATE - java.lang.Long - - - PRIORITY - java.lang.Integer - @@ -116,6 +96,58 @@ Many inbound and outbound adapter implementations will also provide and/or expect certain headers, and additional user-defined headers can also be configured. +
+ MessageHeaderAccessor API + + Since Spring Framework 4.0 and Spring Integration 4.0, the core Messaging abstraction has been moved to + the spring-messaging module and the new MessageHeaderAccessor API + has been introduced to provide additional abstraction over Messaging implementations. All Spring + Integration specific Message Headers constants are now declared in the + IntegrationMessageHeaderAccessor: + + Pre-defined Message Headers + + + + + Header Name + Header Type + + + + + CORRELATION_ID + java.lang.Object + + + SEQUENCE_NUMBER + java.lang.Integer + + + SEQUENCE_SIZE + java.lang.Integer + + + EXPIRATION_DATE + java.lang.Long + + + PRIORITY + java.lang.Integer + + + +
+ + + Convenient typed getters for these headers are provided on the + IntegrationMessageHeaderAccessor class: + + +
Message ID Generation @@ -129,22 +161,23 @@ A different UUID generation strategy can be selected by declaring a bean that implements - MessageHeaders.IdGenerator in the application context. + org.springframework.util.IdGenerator in the application context. Only one UUID generation strategy can be used in a classloader. This means that if two or more application contexts are running in the same classloader, they will share the same strategy. If one of the contexts changes the strategy, it will be used by all contexts. If two or more contexts in the same classloader declare a bean of type - MessageHeaders.IdGenerator, they must all be an instance + org.springframework.util.IdGenerator, they must all be an instance of the same class, otherwise the context attempting to replace a custom strategy will fail to initialize. If the strategy is the same, but parameterized, the strategy in the first context to initialize will be used. In addition to the default strategy, two additional IdGenerators - are provided; MessageHeaders.JdkIdGenerator uses the previous - UUID.randomUUID() mechanism; MessageHeaders.SimpleIncrementingIdGenerator + are provided; org.springframework.util.JdkIdGenerator uses the previous + UUID.randomUUID() mechanism; + org.springframework.integration.support.IdGenerators.SimpleIncrementingIdGenerator can be used in cases where a UUID is not really needed and a simple incrementing value is sufficient. @@ -163,7 +196,7 @@ new GenericMessage<T>(T payload, Map<String, Object> headers) - There is also a convenient implementation of Message designed to communicate + There is also a convenient implementation of Message designed to communicate error conditions. This implementation takes Throwable object as its payload: ErrorMessage message = new ErrorMessage(someThrowable); @@ -229,7 +262,7 @@ assertEquals(123, message4.getHeaders().get("foo")); assertEquals(5, importantMessage.getHeaders().getPriority()); Message<Integer> lessImportantMessage = MessageBuilder.fromMessage(importantMessage) - .setHeaderIfAbsent(MessageHeaders.PRIORITY, 2) + .setHeaderIfAbsent(IntegrationMessageHeaderAccessor.PRIORITY, 2) .build(); assertEquals(2, lessImportantMessage.getHeaders().getPriority()); diff --git a/src/reference/docbook/resequencer.xml b/src/reference/docbook/resequencer.xml index 1dada919d1..01529a7ed6 100644 --- a/src/reference/docbook/resequencer.xml +++ b/src/reference/docbook/resequencer.xml @@ -111,7 +111,7 @@ algorithm. The bean can be an implementation of the CorrelationStrategy interface or a POJO. In the latter case the correlation-strategy-method attribute must be defined as well. Optional (by default, the aggregator will use - the MessageHeaders.CORRELATION_ID header) . + the IntegrationMessageHeaderAccessor.CORRELATION_ID header) . @@ -133,7 +133,7 @@ The bean can be an implementation of the ReleaseStrategy interface or a POJO. In the latter case the release-strategy-method attribute must be defined as well. Optional (by default, the - aggregator will use the MessageHeaders.SEQUENCE_SIZE header attribute). + aggregator will use the IntegrationMessageHeaderAccessor.SEQUENCE_SIZE header attribute).