Jakarta Commons Digester VS XMLBeans

Jakarta Commons Digester

Many Jakarta projects read XML configuration files to provide initialization of various Java objects within the system. There are several ways of doing this, and the Digester component was designed to provide a common implementation that can be used in many different projects. Basically, the Digester package lets you configure an XML -> Java object mapping module, which triggers certain actions called rules whenever a particular pattern of nested XML elements is recognized. A rich set of predefined rules is available for your use, or you can also create your own. Advanced features of Digester include:

* Ability to plug in your own pattern matching engine, if the standard one is not sufficient for your requirements.

* Optional namespace-aware processing, so that you can define rules that are relevant only to a particular XML namespace.

* Encapsulation of Rules into RuleSets that can be easily and conveniently reused in more than one application that requires the same type of processing.

XMLBeans

At a high level XMLBeans is an XML-Java binding tool that uses XML Schema as a basis for generating Java classes that you can use to easily access XML instance data in a natural manner in your Java programs. It was designed to provide both easy access to XML information via convenient Java classes as well as complete access to the underlying XML, combining the best of low-level APIs like SAX and DOM that provide full access with the convenience of Java binding. There are several factors that set XMLBeans apart from any other XML-Java binding alternatives:

* XML Schema Compliance - XMLBeans has achieved extremely high schema compliance and is able to compile even the most complex schemas. This is critical when adopting an XML-Java binding framework since you may received schemas that are out of your control.

* Access to the full underlying XML Infoset - The XML Cursor API allows you to access a lower level DOM like access to the underying XML Infoset. You can get a "cursor" at any point while using the strongly typed generated XMLBeans and begin navigating the underlying XML instance.

* Access to the schema type system - The XMLBeans schema API allows you to walk through the schema type system giving you full access to a Java object representation of the XML Schema that was compiled to generate the XMLBeans classes.

* Speed - XMLBeans is optimized for performance at many levels. For example, XMLBeans lazily constructs objects from XML, so that you do not have the performance overhead of object creation when you only access portions of an XML document. Several Fortune 500 customers have adopted XMLBeans based on speed alone.

Digester Vs XMLBeans

Digester is just a convenient thin wrapper for SAX. it's mostly used as a xml to object mapper, but not the object to xml.
It executes rules when certain SAX events are received. this means that it can be used for purposes other than just mapping and that as a mapper it is very, very flexible and extensible.

JAXB, xml beans and castor. they provide complet marshalling and unmarshalling services. They map object graphs into xml and verse-versa.

If we have an xml-schema or DTD and want to generate java beans then a generative start-from-xml solution is most suitable. if you have an existing object model that you want to express as xml then a
start-from-java will be more suitable.

if you have an object model that you want to build up from xml then digester is a very good match. there's a lot less to learn than a object <-> xml mapper - especially if you write your own rules. Digester is often a better match if you already have
a particular object model and you don't care about Object to XML mapping.

in terms of performance, digester is a very thin wrapper around SAX and so is efficient providing that you're willing to avoid reflection by writing your own rules. the best plan is probably to start with the rules that digester ships with and then optimize if performance becomes
an issue.