 |  |
| |
The API chapters wouldn't be complete without letting you know about some problems that I frequently run into or that I'm asked about. Hopefully they'll help save you some time, and maybe make your code more bug-proof. Read on, and see where JAXP catches folks these days.
It's worth saying again: the implementation of JAXP determines the default parser. If you switch the JAXP implementation, you often end up switching the parser that is used, if you haven't set any system properties for JAXP. Your classpath may have to change, or you will get all sorts of ClassNotFoundExceptions.
To avoid this problem completely, you could simply set the relevant JAXP system property to the parser factory you want to use, and regardless of what implementation you choose, you'll get expected behavior. Or better yet, put a jaxp.properties file in the lib directory of your Java installation.[15] This file can be as simple as this:
[15]This option assumes that you have set the JAVA_HOME environment variable to the installation directory of your JDK. It assumes that because it's a good, if not mandatory, practice and will help you out in the long term. JAXP looks, in actuality, for %JAVA_HOME%/lib/jaxp.properties.
javax.xml.parsers.SAXParserFactory org.apache.xerces.XercesFactory
By changing the factory implementation, you change the parser wrapper that is returned from calls to newSAXParser( ). And lest you try the example file given, the org.apache.xerces.XercesFactory class doesn't exist; it's just for example purposes. It happened to fit within the confines of the code block!
One common mistake is to mix up factories and properties in the JAXP world. The best way to remember the correct application is to memorize the phrase "features on factories, properties on parsers." You would be amazed at the number of mails I get insisting that the sender has a "corrupt" version of JAXP, because the following code won't compile:
SAXParserFactory factory = SAXParserFactory.newInstance( );
factory.setProperty(
"http://apache.org/xml/properties/dom/document-class-name",
"org.apache.xerces.dom.DocumentImpl");Of course, this is a property, and therefore must be set on a SAXParser instance, not a SAXParserFactory instance. The reverse, of course, holds true for setting features on parsers:
SAXParser parser = factory.newSAXParser( );
parser.setFeature("http://xml.org/sax/features/namespaces", true);In either case, it is user error, not a strange download problem where all but a few methods came across OK (I generally refer these people to some good books on I/O). This is also a good case of the Javadocs not being used when they should. I'm a firm believer in the value of Javadoc.
|  | |
| 9.3. JAXP 1.1 |  | 9.5. What's Next? |
Copyright © 2002 O'Reilly & Associates. All rights reserved.