I would recommend passing XML not as text but use the ObjectMessage format.
Since Xerces (probably what you use) uses serializable org.w3c.dom objects, just set the message to use the Document object.
Watch your stack size if you are serializing a DOM object.
If you use the JBoss recommended stack size of 128k (http://wiki.jboss.org/wiki/Wiki.jsp?page=OutOfMemoryExceptionWhenCannotCreateThread) you may run into problems serializing large DOM nodes.
i have done it this way.
document.appendChild(rootElement); TransformerFactory tFactory = TransformerFactory.newInstance(); Transformer transformer = tFactory.newTransformer(); DOMSource source = new DOMSource(document); StringWriter buffer = new StringWriter(); StreamResult result = new StreamResult(buffer); transformer.transform(source, result); xmlString = buffer.toString();
where document is DOcument object of DOM , and passing this xmlString in the TestMessage body .
Is this wrong way of doing it.
and crazytony please also tell me what was that stack thing and outofmemory thing you were talkin about. since my Document object is going to be large.
and genman i will try ObjectMessage and let you know, but i had read in the specs that XML messages can be send using TextMessages , so did that
genman was saying that you should just send the whole DOM tree (put the parent Node in an ObjectMessage).
Just watch out if you change the stack size because DOM is a deeply recursive structure and the default java serialization is also very recursive.
Basically, what he was saying was: session.createObjectMessage( rootElement );
We've found that this will blow the 128k stack about 1/2 of the time (for our XML, YMMV). We've actually adopted a similar idea to you, send the string and parse it on the other side (message receiver)
It does depend on the XML tree depth. If you use something like JDom or Dom4J as your object model, you might get different allowable tree depths.
XML serialization/parsing is inefficient compared to Java serialization.
Agreed, an additional serialize/parse is a bad thing. I was just pointing out a pitfall which caused us quite a headache.
In an ideal world, we wouldn't need to change the stack size to fix a problem with thread creation and this would all be moot.
We didn't need the node on the sender side of the message (it came from an XML HTTP request) so there was no additional overhead involved in sending it as a string.