DefaultXmlPayloadConverter - XmlBeans

[jebscar]

We are marshaling JMS messages to XmlBeans objects using a channel interceptor. We then want to route the message using the xpath router. unfortunately it appears the DefaultXmlPayloadConverter does not convert XmlBeans XmlObject to a Node object and therefore the xpath router does not execute.

It looks like it could be accomplished by modifying DefaultXmlPayloadConverter to include additional condition for XmlObject as show below. I am sure there is a more elegant solution and their may need more thought if additional marshalling frameworks need support. Allowing the set a custom XmlPayloadConverter on the xpath router in config could help as well so that the entire xpath route bean definitions does not have to be created in order to set.

	public Node convertToNode(Object object) {
		Node node = null;
		if (object instanceof Node) {
			node = (Node) object;
		}
		else if (object instanceof DOMSource) {
			node = ((DOMSource) object).getNode();
		}
		else if	(object instanceof XmlObject){
			node = ((XmlObject)object).newDomNode();
		}
		else {
			node = convertToDocument(object);
		}
		return node;
	}

[oleg.zhurakousky]

Couple of things.
"marshaling JMS messages to XmlBeans" - From the EIP perspective this is transformation so I would do in in the transformer instead. Although Channel interceptors do the job for you currently they were not designed for that. Typical use of channel interceptor is for logging and auditing (e.g., wire-tap pattern)

As for the second question you can again use transformer to transform to/from XmlObject. DefaultXmlPayloadConverter was not designed to support every single XML framework.

Hope that helps

[jebscar]

Thank Oleg, couple follow ups..

what is the intended purpose of MessageTransformingChannelInterceptor? our config is show below. If we are misusing that may result in unintended consequence I want to make sure we correct this.

If a custom XmlPayloadConverter could be specified on the xpath-router definition then additional marshaling frameworks would be easier to use for users, no?

	<int:channel id="channel">
 		<int:interceptors>
			<bean class="org.springframework.integration.transformer.MessageTransformingChannelInterceptor">
	      		<constructor-arg>
	      			<bean class="org.springframework.integration.xml.transformer.UnmarshallingTransformer">
					  <constructor-arg>
					    <bean class="org.springframework.oxm.xmlbeans.XmlBeansMarshaller"/>
					  </constructor-arg>
					</bean>
	      		</constructor-arg>
			</bean>
		</int:interceptors>
	</int:channel>

[Mark Fisher]

Feel free to open a JIRA for exposing the "converter" attribute on the <xpath-router> element. The underlying object accepts a custom implementation of XmlPayloadConverter so that would provide an easy hook for you to add your own logic there. For now, you could create the XPathRouter as a simple <bean>, but we might as well expose that attribute since it would only require one new line of code in the parser.

Thanks,
Mark

[oleg.zhurakousky]

MessageTransformingChannelInterceptor - probably something that we should have never had since it conflicts with the transformer (one of the early classes). I am going to raise a JIRA for deprecating it so I'd suggest not to use it. In fact it is not used by the framework anywhere outside of a single test case - MessageTransformingChannelInterceptorTests