Other Java XML Notes

The Document building code is not guaranteed to be well behaved in threads. You may very well have many XML files to parse, and you may want to use a thread for each. An implementation of the DocumentBuilderFactory class is not guaranteed to be thread safe. To avoid problems, the application can get a new instance of the DocumentBuilderFactory per thread, and they can be configured differently in terms of how much validation they do, whether they ignore comments and so on.

Here's how we use the Factory instance to get back a Parser that has the type of the abstract class javax.xml.parsers.DocumentBuilder:

... myDb = myDbf.newDocumentBuilder();

Now that we have a DocumentBuilder (which is actually a Pete'sPrettyGoodParser, or equivalent), we can use it in a type-safe, future-proof way to parse an XML file and build the corresponding document, like this:

org.w3c.dom.Document doc = myDb.parse( new File("myData.xml"));

We did not simply move the dependency from your code into the run-time library. The JAXP run-time library has put the hooks in place to make it possible to switch parser implementations. The full details are the in the Specification document which you will download. However, to summarize, the run-time looks for a property file that contains the class name of any different parser you want to use. If the property is not found, it uses the default. So it all works as desired. Everything is hands-off. You're manipulating the tree by remote control, which admittedly makes this harder to follow.

Factory pattern confusion in Java XML

The folks at Javasoft designed this with a double example of the factory pattern. First, you get a Factory, from that you get a ParserFactory, then you get a parser, then you parse. Even worse, they made the code more confusing by using the same class (DocumentBuilderFactory) for both Factories! The code looks like this:

// Step 1: instantiate a DocumentBuilderFactory
      DocumentBuilderFactory dbf =
          DocumentBuilderFactory.newInstance();
// Step 2:   Use the factory pattern again to get db
      DocumentBuilder db = dbf.newDocumentBuilder();
// Step 3: now actually use db as a parser
      Document doc = db.parse( "cd.xml" );

They wrote code to get a Factory using the Factory pattern! The algorithm used is “first get a factory instance, then use that to get a parser instance,” but it would work just as well and be a lot clearer if DocumentBuilderFactory had a static factory method to return a DocumentBuilder directly.

I asked around in Javasoft to see why this was done, and the answer was it was a holdover from the early days of the API. The intent was to keep all the methods that configure the parser in one factory. Then once a parser had been configured and set up to be instantiated, you could use the builder class to get hold of the parser that had been configured and also use the convenience methods in there. For example, say you had just one factory and you started parsing and building a document. Then what would it mean if you changed one of the configurations in the middle? Does it affect the current parser or does it instantiate a new parser and take effect from then on? To avoid all this, once a parser has been configured, you can't change the configuration unless you get a new instance of the parser.

A much better way to solve the problem is to do what SAX 2.0 does if you try to reconfigure the parser during a parse, which is to throw an exception. This has the advantage of eliminating an extra class in the API and makes it easier to use. It's water under the bridge at this point, and we have to live with the unnecessary complexity. Moral: Keep your code obvious, and it will be easier to maintain.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.227.26.217