XML Parser for Java

The SilverStream Application Server Version 3.5 includes the IBM XML Parser for Java (XML4J) Version 3.0.1. SilverStream Version 3.0 included Version 2.0.15 of XML4J.

About the XML parser

In November 1999, IBM turned over XML4J to the Apache group (xml.apache.org). Apache renamed it Xerces, and they now maintain it through Open Source development (with major contributions from IBM and others).

Apache puts out regular releases, but does not really make a distinction between beta-quality releases and production-quality releases. However, IBM takes certain releases of Xerces, tests them for quality, adds backwards-compatibility classes, and releases them as XML4J. As of June 2000, IBM's current release is XML4J 3.0.1, which is the same code as Xerces 1.0.3. In order to keep the XML support current, the SilverStream Application Server Version 3.5 includes XML4J 3.0.1.

Using XML with SilverStream

For information about using XML with SilverStream, see the online chapter on XML in the Programmer's Guide.

If you had been using Version 2.0.15 of XML4J with SilverStream Version 3.0, read the following information about updating from XML4J Version 2.0.15.

Updating from XML4J 2.0.15

The update from XML4J 2.0.15 to XML4J 3.0.1 should be easy, but there may be some code changes you'll have to make. The Apache group has renamed the com.ibm.xml tree to org.apache.xerces, but IBM includes compatibility classes with the old names. This should allow most existing code to continue to work.

There were some small changes however. One change affects the DOM parser, and the other affects the SAX parser.

DOM parser

com.ibm.xml.parsers.DOMParser no longer implements org.xml.sax.Parser. This means that (a) you can't use ParserFactory.makeParser() to construct this parser, and (b) you can't reference it as an org.xml.sax.Parser to call methods like setEntityResolver() or setErrorHandler() on it (even though these methods still exist on the class).

However, these problems are easy to work around. Just replacing all instances of org.xml.sax.Parser with com.ibm.xml.parsers.DOMParser and directly newing up a com.ibm.xml.parser.DOMParser instead of using ParserFactory.makeParser(), should do the trick.

Thus the following old code:

  org.xml.sax.Parser parser = ParserFactory.makeParser("com.ibm.xml.parser.DOMParser"); 
  parser.setErrorHandler(...); 
  parser.setEntityResolver(...); 
  parser.parse(...); 
  org.w3c.dom.Document d = ((DOMParser)parser).getDocument(); 

becomes:

  com.ibm.xml.parser.DOMParser parser = new com.ibm.xml.parser.DOMParser(); 
  parser.setErrorHandler(...); 
  parser.setEntityResolver(...); 
  parser.parse(...); 
  org.w3c.dom.Document d = parser.getDocument(); 

You lose the flexibility that the Parser interface and the ParserFactory factory provided, but this is unavoidable with the upgrade, since there is no common interface for DOM parsers as there is for SAX parsers.

SAX parser

This change has to do with the char arrays passed to your DocumentHandler implementation in characters() and ignorableWhitespace(). In XML4J 2.0.15, the parser would send them in such a way that it was often possible to use and store the char arrays directly, without making a copy of the data. In 3.0.1, however, the char arrays are reused across calls, so if you want to keep the data around, you must copy it. For example, you could create a new char array and use System.arraycopy to copy the data into it, or you could simply do new String(ch, start, length).