Built-in Processors

The WebLogic distribution comes equipped with a number of standard XML parsers and transformers: the Apache-based Xerces and Xalan libraries, which provide the SAX and DOM parsers as well as the XSLT transformer. You also can use WebLogic's own FastParser, which is a fast, nonvalidating SAX parser.

18.2.1 WebLogic's FastParser

WebLogic's FastParser is a high-performance, nonvalidating SAX parser. It has been designed for processing small to medium-size documents documents that contain no more than 10,000 elements. This is typical of many web service applications, in which SOAP and WSDL documents tend to be small. The Streaming API, which we'll cover later, is based on WebLogic's FastParser.

Because the FastParser supports the SAX interface, you can use it instead of WebLogic's default SAX parser, Apache Xerces. By configuring an XML Registry to use the FastParser factory, you ensure that your JAXP code automatically uses the FastParser for processing an XML document.

Clearly, you cannot use the nonvalidating FastParser to validate XML documents.

18.2.2 Using JAXP-Compliant Parsers

The default parsers supplied with WebLogic are based on Apache's Xerces 2.1.0 and Xalan 2.2 libraries. They provide full support for SAX and DOM parsing, as well as XSL transformers. However, you are not required to use these parsers. For instance, you could upgrade the Xerces parser to a newer version that supports the current W3C XML Schema recommendation.

All parser implementations work on a factory design pattern, as we saw in the examples earlier in this chapter. The JAXP interface hides the actual parser class being used, but it also can be exposed in certain situations. For instance, the print statement in Example 18-2 yields weblogic.apache.xerces.dom.DOMImplementationImpl as its output. This indicates that we were using WebLogic's default DOM parser, based on Xerces.

When you configure WebLogic to use a particular parser or transformer implementation, it is important to know the fully qualified class names of the factories that manufacture the parsers or transformers. Table 18-1 lists the class names for WebLogic's default DOM, SAX, and transformer factories.

Table 18-1. Default XML factories for WebLogic Server

XML factory	Class name
DOM parser	weblogic.apache.xerces.jaxp.DocumentBuilderFactoryImpl
SAX parser	weblogic.apache.xerces.jaxp.SAXParserFactoryImpl
XSL Transformer	org.apache.xalan.processor.TransformerFactoryImpl
FastParser	weblogic.xml.babel.jaxp.SAXParserFactoryImpl

In some cases, you may want to bypass the JAXP layer and instantiate a parser directly. For instance, you could instantiate WebLogic's DOM parser directly as follows:

import weblogic.apache.xerces.parsers.*;
...
DocumentBuilderFactory dbf = DocumentBuilderFactoryImpl.newInstance( );
DocumentBuilder db = dbf.newDocumentBuilder( );

However, it also means that your applications are less portable and you need more code changes when you need to change the DOM parser implementation. The following code snippet shows how you can use the Xerces-derived SAX parser implementation directly:

import weblogic.apache.xerces.parsers.*;
...
SAXParserFactory spf = SAXParserFactoryImpl.newInstance( );
SAXParser sp = spf.newSAXParser( );

Ideally, you should use the generic JAXP interfaces to create an XML parser or an XSL transformer. If you want to use another library, you should configure WebLogic separately with the desired parser factories. In fact, the XML Registry allows you to configure this on a per-server basis.

In some situations, you may need to use more than one parser implementation. For example, you may want to use the FastParser for SOAP documents, and a standard SAX parser for other XML processing within your application. There are two ways in which to achieve this:

• Use the XML Registry to target a parser to a particular document, based on its root element (for instance). This allows you to continue using the standard JAXP interface to retrieve parsers and processors.
• Bypass the JAXP interface altogether and directly use the API provided by the parser implementation. This approach means sacrificing application portability.