此版本仍在开发中，尚未被视为稳定版本。对于最新的稳定版本，请使用 Spring Integration 6.3.4！spring-doc.cn

此版本仍在开发中，尚未被视为稳定版本。对于最新的稳定版本，请使用 Spring Integration 6.3.4！spring-doc.cn

概述

Spring 集成 AMQP 适配器会自动映射所有 AMQP 属性和头文件。 （这是对 4.3 的更改 - 以前，仅映射标准标头）。 默认情况下，这些属性通过使用DefaultAmqpHeaderMapper复制到 Spring 集成或从 Spring 集成复制。MessageHeadersspring-doc.cn

你可以传入你自己的特定于 AMQP 的 Headers 映射器的实现，因为适配器具有支持这样做的属性。spring-doc.cn

AMQP MessageProperties 中的任何用户定义的标头都将复制到 AMQP 消息或从 AMQP 消息中复制，除非 . 默认情况下，对于出站映射器，不会映射任何标头。 请参阅本节后面出现的注意事项，了解原因。requestHeaderNamesreplyHeaderNamesDefaultAmqpHeaderMapperx-*spring-doc.cn

要覆盖默认值并恢复到 4.3 之前的行为，请在属性中使用 and。STANDARD_REQUEST_HEADERSSTANDARD_REPLY_HEADERSspring-doc.cn

映射用户定义的标头时，值还可以包含要匹配的简单通配符模式（如 或 ）。 匹配所有标头。thing**thing*

从版本 4.1 开始，（超类）允许为 和 属性（除了现有的 和 ）配置令牌，以映射所有用户定义的 Headers。AbstractHeaderMapperDefaultAmqpHeaderMapperNON_STANDARD_HEADERSrequestHeaderNamesreplyHeaderNamesSTANDARD_REQUEST_HEADERSSTANDARD_REPLY_HEADERSspring-doc.cn

该类标识 ：org.springframework.amqp.support.AmqpHeadersDefaultAmqpHeaderMapperspring-doc.cn

如本节前面所述，使用 Headers 映射模式是复制所有 Headers 的常见方法。 但是，这可能会产生一些意想不到的副作用，因为某些 RabbitMQ 专有属性/标头也会被复制。 例如，当您使用联合身份验证时，收到的消息可能具有一个名为 的属性，其中包含发送消息的节点。 如果您在入站网关上对请求和回复标头映射使用通配符，则会复制此标头，这可能会导致联合身份验证出现一些问题。 此回复消息可能会联合回发送代理，发送代理可能会认为消息正在循环，因此会以静默方式删除该消息。 如果您希望使用通配符标头映射的便利性，则可能需要筛选掉下游流中的一些标头。 例如，为了避免将 Headers 复制回回复，您可以在将回复发送到 AMQP 入站网关之前使用。 或者，您可以显式列出实际要映射的那些属性，而不是使用通配符。 由于这些原因，对于入站邮件，映射器（默认情况下）不会映射任何报头。 它也不会将 映射到报头，以避免该报头从入站邮件传播到出站邮件。 相反，此标头映射到 ，而 则不会在输出上映射。*x-received-from*x-received-from<int:header-filter …​ header-names="x-received-from">x-*deliveryModeamqp_deliveryModeamqp_receivedDeliveryMode

从版本 4.3 开始，可以通过在模式前面加上 . 否定模式获得优先级，因此 does not map （nor nor ） 等列表 does not map （nor nor ） ）。 标准标头 plus 和 被映射。 否定技术可能很有用，例如，当 JSON 反序列化逻辑在接收方下游以不同的方式完成时，不为传入消息映射 JSON 类型的标头。 为此，应该为入站通道适配器/网关的 Headers Mapper 配置一个模式。!STANDARD_REQUEST_HEADERS,thing1,ba*,!thing2,!thing3,qux,!thing1thing1thing2thing3badqux!json_*spring-doc.cn

如果您有一个用户定义的标头，该标头以您希望映射的开头，则需要使用 ， 对其进行转义，如下所示：。 名为 的标头现已映射。!\STANDARD_REQUEST_HEADERS,\!myBangHeader!myBangHeader
从版本 5.1 开始，如果出站消息中不存在相应的 or 标头，则将分别回退到 mapping 和 to 和 。 入站属性将像以前一样映射到标头。 当消息使用者使用有状态重试时，填充该属性非常有用。DefaultAmqpHeaderMapperMessageHeaders.IDMessageHeaders.TIMESTAMPMessageProperties.messageIdMessageProperties.timestampamqp_messageIdamqp_timestampamqp_*messageId
映射用户定义的标头时，值还可以包含要匹配的简单通配符模式（如 或 ）。 匹配所有标头。thing**thing*
如本节前面所述，使用 Headers 映射模式是复制所有 Headers 的常见方法。 但是，这可能会产生一些意想不到的副作用，因为某些 RabbitMQ 专有属性/标头也会被复制。 例如，当您使用联合身份验证时，收到的消息可能具有一个名为 的属性，其中包含发送消息的节点。 如果您在入站网关上对请求和回复标头映射使用通配符，则会复制此标头，这可能会导致联合身份验证出现一些问题。 此回复消息可能会联合回发送代理，发送代理可能会认为消息正在循环，因此会以静默方式删除该消息。 如果您希望使用通配符标头映射的便利性，则可能需要筛选掉下游流中的一些标头。 例如，为了避免将 Headers 复制回回复，您可以在将回复发送到 AMQP 入站网关之前使用。 或者，您可以显式列出实际要映射的那些属性，而不是使用通配符。 由于这些原因，对于入站邮件，映射器（默认情况下）不会映射任何报头。 它也不会将 映射到报头，以避免该报头从入站邮件传播到出站邮件。 相反，此标头映射到 ，而 则不会在输出上映射。*x-received-from*x-received-from<int:header-filter …​ header-names="x-received-from">x-*deliveryModeamqp_deliveryModeamqp_receivedDeliveryMode
如果您有一个用户定义的标头，该标头以您希望映射的开头，则需要使用 ， 对其进行转义，如下所示：。 名为 的标头现已映射。!\STANDARD_REQUEST_HEADERS,\!myBangHeader!myBangHeader
从版本 5.1 开始，如果出站消息中不存在相应的 or 标头，则将分别回退到 mapping 和 to 和 。 入站属性将像以前一样映射到标头。 当消息使用者使用有状态重试时，填充该属性非常有用。DefaultAmqpHeaderMapperMessageHeaders.IDMessageHeaders.TIMESTAMPMessageProperties.messageIdMessageProperties.timestampamqp_messageIdamqp_timestampamqp_*messageId

标头contentType

与其他标头不同，它不以 ;这允许跨不同技术透明地传递 contentType 标头。 例如，发送到 RabbitMQ 队列的入站 HTTP 消息。AmqpHeaders.CONTENT_TYPEamqp_spring-doc.cn

标头映射到 Spring AMQP 的属性，随后映射到 RabbitMQ 的属性。contentTypeMessageProperties.contentTypecontent_typespring-doc.cn

在版本 5.1 之前，此 Headers 也被映射为 Map 中的一个条目;这是不正确的，此外，该值可能是错误的，因为底层 Spring AMQP 消息转换器可能已经更改了内容类型。 此类更改将反映在 first-class 属性中，但不反映在 RabbitMQ 标头映射中。 入站映射忽略了 headers 映射值。 不再映射到 Headers 映射中的条目。MessageProperties.headerscontent_typecontentTypespring-doc.cn