我在mulesoft门户网站上玩example,在这个例子中使用子流时我看到了一些奇怪的行为。
从子流退出时,Payload类类型会发生变化。
有趣的部分在下面
<sub-flow name="Samsung_SubFlow">
<data-mapper:transform config-ref="OrderIrem_To_OrderRequest" doc:name="OrderItem To OrderRequest"/>
<http:request config-ref="HTTP_Request_Configuration" path="samsung/orders" method="POST" port="9090" doc:name="samsung/orders"/> -->
<flow-ref name="samsungWebServiceClient" doc:name="samsungWebServiceClient"/>
<logger message="After just returning into the main flow #[payload]" level="INFO" doc:name="Main flow"/>
<message-property-filter pattern="http.status=200" caseSensitive="true" scope="inbound" doc:name="Filter failures"/>
<set-session-variable variableName="totalCost" value="#[totalCost+payload.price]" doc:name="totalCost=+price"/>
<data-mapper:transform config-ref="OrderResponse_to_PurchaseReceipt" doc:name="OrderResponse to PurchaseReceipt"/>
</sub-flow>
<sub-flow name="samsungWebServiceClient">
<cxf:jaxws-client clientClass="com.mulesoft.se.samsung.SamsungServiceService" doc:name="Samsung Webservice Client" operation="purchase" port="SamsungServicePort"/>
<http:request config-ref="HTTP_Request_Configuration" doc:name="/samsung/orders" method="POST" path="samsung/orders" port="9090"/>
<logger message="At the end of the subflow #[payload]" level="INFO" doc:name="Sub-flow exit"/>
</sub-flow>
两个记录器给出了以下
INFO 2015-05-10 17:32:07,016 [服务配器] .Orders_HTTP_Listener_Configuration.worker.01] org.mule.api.processor.LoggerMessageProcessor:在结束时 subflow org.glassfish.grizzly.utils.BufferInputStream@1ba9d893 INFO 2015-05-10 17:32:15,219
[[服务配器] .Orders_HTTP_Listener_Configuration.worker.01] org.mule.api.processor.LoggerMessageProcessor:刚刚返回 进入主要流程com.mulesoft.se.samsung.OrderResponse@70d5a09f
请注意有效负载类型如何从BufferInputStream更改为OrderResponse !!
我不认为这是预期的行为,因为很明显,如果我将MP从子流嵌入到主流中,则流失败,因为有效载荷类类型不是OrderResponse
答案 0 :(得分:1)
CXF处理器是一个拦截消息处理器,因此它在处理器链执行后立即执行一些操作(在这种情况下是第二个子流)。为了改变这种行为,您可以使用<processor-chain>
标记包围cxf客户端。