|
此版本仍在开发中，尚不被认为是稳定的。对于最新的稳定版本，请使用 Spring Integration 6.5.1！ |
AMQP 消息头
概述
Spring Integration AMQP 适配器会自动映射所有 AMQP 属性和标头。（这是对 4.3 的更改 - 以前，仅映射标准标头）。默认情况下，这些属性被复制到 Spring Integration 或从 Spring Integration 复制MessageHeaders通过使用DefaultAmqpHeaderMapper.
您可以传入自己的 AMQP 特定标头映射器的实现，因为适配器具有支持这样做的属性。
AMQP 中的任何用户定义的标头MessageProperties复制到 AMQP 消息或从 AMQP 消息复制，除非被requestHeaderNames或replyHeaderNames属性DefaultAmqpHeaderMapper. 默认情况下，对于出站映射器，没有x-*标头。有关原因，请参阅本节后面出现的警告。
要覆盖默认值并恢复到 4.3 之前的行为，请使用STANDARD_REQUEST_HEADERS和STANDARD_REPLY_HEADERS在属性中。
映射用户定义的标头时，值还可以包含简单的通配符模式（例如thing*或*thing） 进行匹配。匹配所有标头。* |
从 4.1 版本开始，AbstractHeaderMapper（一个DefaultAmqpHeaderMapper超类）让NON_STANDARD_HEADERS为requestHeaderNames和replyHeaderNames属性（除了现有的STANDARD_REQUEST_HEADERS和STANDARD_REPLY_HEADERS） 来映射所有用户定义的标头。
这org.springframework.amqp.support.AmqpHeadersclass 标识DefaultAmqpHeaderMapper:
-
amqp_appId -
amqp_clusterId -
amqp_contentEncoding -
amqp_contentLength -
content-type（参见这contentType页眉) -
amqp_correlationId -
amqp_delay -
amqp_deliveryMode -
amqp_deliveryTag -
amqp_expiration -
amqp_messageCount -
amqp_messageId -
amqp_receivedDelay -
amqp_receivedDeliveryMode -
amqp_receivedExchange -
amqp_receivedRoutingKey -
amqp_redelivered -
amqp_replyTo -
amqp_timestamp -
amqp_type -
amqp_userId -
amqp_publishConfirm -
amqp_publishConfirmNackCause -
amqp_returnReplyCode -
amqp_returnReplyText -
amqp_returnExchange -
amqp_returnRoutingKey -
amqp_channel -
amqp_consumerTag -
amqp_consumerQueue
正如本节前面提到的，使用 的标头映射模式 是复制所有标头的常用方法。但是，这可能会产生一些意想不到的副作用，因为某些 RabbitMQ 专有属性/标头也会被复制。例如，当您使用联合时，收到的消息可能具有名为*x-received-from，其中包含发送消息的节点。
如果将通配符用于入站网关上的请求和回复标头映射，则会复制此标头，这可能会导致联合出现一些问题。
此回复消息可能会联合回发送代理，发送代理可能会认为消息正在循环，因此会静默地删除它。
如果您希望使用通配符标头映射的便利，您可能需要过滤掉下游流中的某些标头。
例如，为了避免复制*x-received-from标题返回到您可以使用的回复<int:header-filter … header-names="x-received-from">在将回复发送到 AMQP 入站网关之前。
或者，您可以显式列出实际要映射的那些属性，而不是使用通配符。
由于这些原因，对于入站消息，映射器（默认情况下）不会映射任何x-*头。
它也不会映射deliveryMode到amqp_deliveryMode标头，以避免该标头从入站消息传播到出站消息。
相反，此标头映射到amqp_receivedDeliveryMode，未映射到输出上。 |
从版本 4.3 开始，可以通过在模式前面加上!.
否定模式优先，因此列表（例如STANDARD_REQUEST_HEADERS,thing1,ba*,!thing2,!thing3,qux,!thing1不映射thing1（也thing2也不thing3).
标准标头加上bad和qux被映射。
例如，当 JSON 反序列化逻辑在下游接收方以不同的方式完成时，不映射传入消息的 JSON 类型标头，否定技术可能很有用。
为此，一个!json_*应为入站通道适配器/网关的标头映射器配置模式。
如果用户定义的标头以!如果您确实希望映射，则需要使用 转义它，如下所示：\STANDARD_REQUEST_HEADERS,\!myBangHeader.
名为!myBangHeader现在已映射。 |
从 5.1 版本开始，DefaultAmqpHeaderMapper将回退到映射MessageHeaders.ID和MessageHeaders.TIMESTAMP自MessageProperties.messageId和MessageProperties.timestamp分别，如果相应的amqp_messageId或amqp_timestamp出站邮件上不存在标头。
入站属性将映射到amqp_*header 和以前一样。
填充messageId当消息使用者使用有状态重试时，属性。 |
这contentType页眉
与其他标头不同，AmqpHeaders.CONTENT_TYPE前缀不为amqp_;这允许跨不同技术透明地传递 contentType 标头。
例如，发送到 RabbitMQ 队列的入站 HTTP 消息。
这contentTypeheader 映射到 Spring AMQP 的MessageProperties.contentType属性，随后映射到 RabbitMQcontent_type财产。
在 5.1 版之前，此标头也映射为MessageProperties.headers地图;这是不正确的，此外，该值可能是错误的，因为底层 Spring AMQP 消息转换器可能更改了内容类型。
这种变化将反映在头等舱content_type属性，但不在 RabbitMQ 标头映射中。
入站映射忽略了标头映射值。contentType不再映射到标头映射中的条目。