Delegating SAX Parsers vs Digester

Delegating SAX

Parser Handler


SAX Parser Handler.

work I’m working on refactoring / redesigning something that started as a

cool idea. Basically, you register sub handlers to a root handler with the

path you’re interested in getting messages for (like “/document/header/title”

would get you the events for the document title).[Jason


It does sound quite similar to digester

which allows you to register interest in SAX events using abolute paths,

relative paths, wildcards and so forth and apply Rules when the SAX events

fire. Plus there’s default rules for all kinds of things like creating beans,

setting bean properties, invoking methods. There’s a default object stack

so its very handy for parsing XML config files and turning them into your

domain objects.

Competition in open source can be healthy, though I do prefer reuse when

it makes sense since it promotes a bigger user community which often results

in better software. So I’d recommend evaluating digester first to see if the effort of starting your own project

and supporting it is worth the effort.

[James Strachan’s Radio Weblog]

I discovered Digester a few weeks ago and have found it very useful. Couple it

with BeanUtils

and you’ve got a great way of automagically populating your beans from an XML

config. I have a Configuration object that contains a Map of the ‘digested’

name-value pairs and uses BeanUtils.copyProperties to set the fields on any

Object it gets passed. All I have to do is obey the javabean naming conventions

and it just works. For an additional check you could include the bean classname

in the XML and have the Configuration object complain if it was passed an object

of the wrong type.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s