Web Services and XML Documents

For some it's obvious. As it was not for me, I decided to put it on e-paper so that you can google this when you need it.

If you want to exchange XML Document, meaning the whole content of an XML file, with Web services, you should not use org.w3c.dom.Document or any other object representation of your XML DOM tree in your method signature. Instead, you should be using a Plain Old Types (POT) like String or byte[].

Take the following code sample, here using JSR-181 annotations:

public Document getDocument(String input) {
  Document res = null;
  try {
    DOMParser builder = new DOMParser();
    builder.parse(new StringReader(STR_XML_DOCUMENT));
    res = builder.getDocument();
  } catch (Exception ex) {
  return res;

private static final String STR_XML_DOCUMENT =
  "<?xml version=\"1.0\"?>\n" +
  "<!DOCTYPE module PUBLIC\n" +
  "\"-//Puppy Crawl//DTD Check Configuration 1.2//EN\"\n" +
  "\"http://www.puppycrawl.com/dtds/configuration_1_2.dtd\">\n" +
  "\n" + "<module name=\"Checker\">\n" +
  " <!-- Comments are safe -->\n" +
  " <metadata name=\"com.atlas-sw.eclipse\" value=\"I like   Sydney\"/>\n" +

You will be able to assemble and deploy the service endpoint just fine, but it may not behaves as once could expect. The SOAP Response carries only the inner Element; the <module> node.

<?xml version="1.0" encoding="UTF-8"?>
    <ans1:getDocumentResponse        xmlns:ans1="http://rajkovic.org/">
        <module name="Checker">
          <metadata name="com.atlas-sw.eclipse" value="I like Sydney"/>

If the PI, CDATA or comments are important to you, using org.w3c.dom.Document or org.w3c.dom.Element is not an option. Instead, you should be using xsd:string or some binary data type like byte[].


ps. This information is based on the current release of JDeveloper.


Popular posts from this blog

Changing the version of JDK used by JDeveloper

Connection reset from a WCF Web Service

Test locally first, then deploy to the cloud.