Mule - 스트림 유형에 대한 StreamCloser를 찾을 수 없습니다. class java.lang.String

Question

JMS 메시지가 대기열로 전달 된 후 Stream Closer와 관련된 log 문이 나타납니다. 그것은 나에게 보이지 않는다. 왜이 메시지를 보나요?

2013-04-22 19:08:29,385 [DEBUG] org.mule.transport.jms.activemq.ActiveMQJmsConnector - Returning dispatcher for endpoint: jms://retry.queue = EeJmsMessageDispatcher{this=5c5801d7, endpoint=jms://retry.queue, disposed=false} 
2013-04-22 19:08:29,433 [DEBUG] org.mule.util.DefaultStreamCloserService - Unable to find an StreamCloser for the stream type: class java.lang.String, the stream: <?xml version="1.0" encoding="UTF-8"?> < ....... rest of the XML ....... /> will not be closed. 

"스트림은 닫히지 않을 것입니다."

이 문제를 해결하려면 어떻게해야합니까?

==== 편집 :

오류가 발생했습니다. JMS 메시지에는 페이로드로 XML이 있습니다. 뮬 버전 : 3.3.2

여기 DEBUG 수준에서

<flow name="sendToHost"> 
    <jms:inbound-endpoint queue="host.queue" exchange-pattern="one-way" /> 
    <copy-properties propertyName="*" />  
    <file:outbound-endpoint path="/hostmessages" outputPattern="outgoing-xml-[function:dateStamp].log" /> 
    <set-variable variableName="hostXML" value="#[payload]" /> 
    <flow-ref name="webServiceCall" /> 
    <flow-ref name="inspectWSResponse" /> 
    <exception-strategy ref="retryExceptionStrategy" /> 
</flow> 

<flow name="resendFailedMessages"> 
    <description> 
     "*/15 07-18 * * ?" run every 15 minutes from 7 am to 6 pm every day --> 
    </description> 
    <quartz:inbound-endpoint jobName="hostRedeliveryJob" cronExpression="0 0/1 * * * ?"> 
     <quartz:endpoint-polling-job> 
      <quartz:job-endpoint ref="redeliverToHost" /> 
     </quartz:endpoint-polling-job> 
    </quartz:inbound-endpoint> 
    <set-variable variableName="hostXML" value="#[payload]" /> 
    <logger message="QUARTZ found message for host" level="INFO" /> 
    <flow-ref name="webServiceCall" /> 
    <flow-ref name="inspectWSResponse" /> 
    <exception-strategy ref="retryExceptionStrategy" /> 
</flow> 

<choice-exception-strategy name="retryExceptionStrategy"> 
    <catch-exception-strategy when="#[exception.causedBy(java.io.IOException)]"> 
     <logger message="In retryExceptionStrategy IO exception strategy. " level="ERROR" /> 
     <logger message="retryExceptionStrategy exception is #[exception.causeException]" level="ERROR" /> 
     <set-property propertyName="exception" value="#[exception.summaryMessage]" /> 
     <set-payload value="#[hostXML]" /> 
     <logger message="retryExceptionStrategy payload is #[payload]" level="ERROR" /> 
     <jms:outbound-endpoint queue="retry.queue" /> 
    </catch-exception-strategy> 
    <catch-exception-strategy> 
     <logger message="Other error in sending result to host in retryExceptionStrategy flow." level="INFO" /> 
     <set-property propertyName="exception" value="#[exception.summaryMessage]" /> 
     <set-payload value="#[hostXML]" /> 
     <jms:outbound-endpoint queue="declined.queue" /> 
    </catch-exception-strategy> 
</choice-exception-strategy> 

<sub-flow name="webServiceCall"> 
    <cxf:proxy-client payload="body" enableMuleSoapHeaders="false"> 
     <cxf:inInterceptors> 
      <spring:bean class="org.apache.cxf.interceptor.LoggingInInterceptor" /> 
     </cxf:inInterceptors> 
     <cxf:outInterceptors> 
      <spring:bean class="org.apache.cxf.interceptor.LoggingOutInterceptor" /> 
     </cxf:outInterceptors> 
    </cxf:proxy-client> 

    <outbound-endpoint address="${host.ws.url}" mimeType="text/xml" connector-ref="http.connector" /> 
    <byte-array-to-string-transformer /> 
</sub-flow> 

<sub-flow name="inspectWSResponse"> 
    <choice> 
     <when expression="#[xpath('//acord:TestResult/acord:TestCode/acord:Name/@tc').value == '1']"> 
      <logger message="Message Delivered Successfully to host" level="INFO" /> 
     </when> 
     <otherwise> 
      <set-payload value="#[hostXML]" /> 
      <jms:outbound-endpoint queue="declined.queue" /> 
     </otherwise> 
    </choice> 
</sub-flow> 

Answer 1

로그 항목은 일반적으로 무시해도 내 흐름이다.

이 특별한 경우에는 Mule이 메시지 페이로드에 스트림이 아닌 문자열 인 StreamCloserService을 사용하고있는 것처럼 보입니다.

소스 코드를 보면 예외가 처리되고 Mule이 스트리밍 페이로드를 실제로 스트리밍 중인지 먼저 확인하지 않고 강제로 닫으려고 할 때만 발생할 수 있습니다. 이것은 양성이며 아무런 부작용도 일으키지 않으므로이 DEBUG 문을 무시해도됩니다.