|
对于最新的稳定版本，请使用 Spring Integration 6.3.1！ |
|
对于最新的稳定版本，请使用 Spring Integration 6.3.1！ |
Spring Integration 通过依赖一些默认规则和定义某些约定，实现了一种灵活的功能，可以在不提供额外配置的情况下将消息映射到方法及其参数。 以下各节中的示例阐明了这些规则。
示例方案
下面的示例显示了一个未批注的参数（对象或基元），该参数不是具有非 void 返回类型的对象或对象：MapProperties
public String doSomething(Object o);输入参数是消息负载。 如果参数类型与消息有效负载不兼容，则尝试使用 Spring 3.0 提供的转换服务进行转换。 返回值将合并为返回消息的有效负载。
下面的示例显示了一个未批注的参数（对象或基元），该参数不是返回类型的 a 或 a：MapPropertiesMessage
public Message doSomething(Object o);输入参数是消息负载。 如果参数类型与消息有效负载不兼容，则尝试使用 Spring 3.0 提供的转换服务进行转换。 返回值是发送到下一个目标的新构造消息。
下面的示例显示了一个参数，该参数是具有任意对象或基元返回类型的消息（或其子类之一）：
public int doSomething(Message msg);输入参数本身是 .
返回值成为发送到下一个目标的有效负载。MessageMessage
下面的示例演示一个参数，该参数是 （或其子类之一） ，其返回类型为 （或其子类之一）：MessageMessage
public Message doSomething(Message msg);输入参数本身是 .
返回值是发送到下一个目标的新构造值。MessageMessage
以下示例显示了类型为 或 a 作为返回类型的单个参数：MapPropertiesMessage
public Message doSomething(Map m);这个有点意思。
虽然，乍一看，这似乎很容易直接映射到消息标头，但始终优先考虑有效负载。
这意味着，如果有效负载的类型为 ，则此输入参数表示有效负载。
但是，如果有效负载不是 类型，则转换服务不会尝试转换有效负载，并且输入参数将映射到消息标头。MessageMessageMapMessageMessageMap
下面的示例显示了两个参数，其中一个参数是任意类型（对象或基元），不是 或 对象，另一个参数是类型或类型（无论返回值如何）：MapPropertiesMapProperties
public Message doSomething(Map h, <T> t);此组合包含两个输入参数，其中一个参数的类型为 。
非参数（无论顺序如何）被映射到有效负载，或者（无论顺序如何）被映射到消息标头，这为你提供了一种与结构交互的很好的POJO方式。MapMapMessageMapPropertiesMessage
以下示例显示未显示任何参数（无论返回结果如何）：
public String doSomething();此消息处理程序方法基于发送到此处理程序所连接的输入通道的消息来调用。
但是，不会映射任何数据，从而使该行为成为事件或触发器来调用处理程序。
输出根据前面描述的规则进行映射。MessageMessage
以下示例显示无参数和 void 返回值：
public void soSomething();此示例与上一个示例相同，但不生成任何输出。
基于注释的映射
基于注释的映射是将消息映射到方法的最安全、最不明确的方法。 下面的示例演示如何将方法显式映射到标头：
public String doSomething(@Payload String s, @Header("someheader") String b)正如您稍后所看到的，如果没有注释，此签名将导致模棱两可的条件。
但是，通过将第一个参数显式映射到有效负载，将第二个参数映射到消息标头的值，我们可以避免任何歧义。Messagesomeheader
以下示例与前面的示例几乎相同：
public String doSomething(@Payload String s, @RequestParam("something") String b)@RequestMapping或任何其他非 Spring Integration 映射注释都是无关紧要的，因此被忽略，使第二个参数未映射。
尽管第二个参数可以很容易地映射到有效负载，但只能有一个有效负载。
因此，注释使此方法不具有歧义性。
以下示例显示了另一种类似的方法，如果不通过注释来阐明意图，该方法将是模棱两可的：
public String foo(String s, @Header("foo") String b)唯一的区别是，第一个参数隐式映射到消息负载。
下面的示例显示了另一个签名，如果没有注释，该签名肯定会被视为模棱两可，因为它有两个以上的参数：
public String soSomething(@Headers Map m, @Header("something") Map f, @Header("someotherthing") String bar)这个例子特别有问题，因为它的两个参数是实例。
但是，使用基于注释的映射，可以轻松避免歧义。
在此示例中，第一个参数映射到所有消息标头，而第二个和第三个参数映射到名为“something”和“someotherthing”的消息标头的值。
有效负载未映射到任何参数。Map
复杂场景
以下示例使用多个参数：
在确定适当的映射时，多个参数可能会产生很多歧义。
一般建议使用 、 和 来注释方法参数。
本节中的示例显示了导致引发异常的不明确条件。@Payload@Header@Headers
public String doSomething(String s, int i)这两个参数的权重相等。 因此，无法确定哪一个是有效载荷。
以下示例显示了类似的问题，但只有三个参数：
public String foo(String s, Map m, String b)尽管 Map 可以很容易地映射到消息标头，但无法确定如何处理这两个 String 参数。
以下示例显示了另一个不明确的方法：
public String foo(Map m, Map f)尽管有人可能会争辩说，一个可以映射到消息有效负载，另一个可以映射到消息标头，但我们不能依赖顺序。Map
任何具有多个方法参数且不是 （， ） 且参数未注释的方法签名都会导致不明确条件并触发异常。Map<T> |
下一组示例分别显示了导致歧义的多种方法。
具有多个方法的消息处理程序基于前面描述的相同规则（在示例中）进行映射。 但是，某些方案可能仍然看起来令人困惑。
以下示例显示了具有合法（可映射和明确）签名的多个方法：
public class Something {
public String doSomething(String str, Map m);
public String doSomething(Map m);
}（无论方法具有相同的名称还是不同的名称都没有区别）。
可以映射到任一方法。
当消息负载可以映射到并且消息标头可以映射到 时，将调用第一种方法。
第二种方法也可以通过仅将消息标头映射到 来成为候选方法。
更糟糕的是，这两种方法的名称相同。
起初，由于以下配置，这可能看起来模棱两可：Messagestrmm
<int:service-activator input-channel="input" output-channel="output" method="doSomething">
<bean class="org.things.Something"/>
</int:service-activator>它之所以有效，是因为映射首先基于有效负载，然后基于其他所有内容。 换言之，其第一个参数可以映射到有效负载的方法优先于所有其他方法。
现在考虑另一个示例，它产生了一个真正模棱两可的条件：
public class Something {
public String doSomething(String str, Map m);
public String doSomething(String str);
}这两种方法都具有可映射到消息有效负载的签名。
它们也有相同的名称。
此类处理程序方法将触发异常。
但是，如果方法名称不同，则可以使用属性（在下一个示例中显示）来影响映射。
下面的示例演示具有两个不同方法名称的同一示例：method
public class Something {
public String doSomething(String str, Map m);
public String doSomethingElse(String str);
}下面的示例演示如何使用该属性来指定映射：method
<int:service-activator input-channel="input" output-channel="output" method="doSomethingElse">
<bean class="org.bar.Foo"/>
</int:service-activator>由于配置显式映射了方法，因此我们消除了歧义。doSomethingElse
任何具有多个方法参数且不是 （， ） 且参数未注释的方法签名都会导致不明确条件并触发异常。Map<T> |