Page History

...

The original authors of the xmlrules project obviously thought it a good idea. However none of them have been involved in Digester development for many years now.saw sufficient advantages to make it worth implementing the feature.

Opponents of xmlrules

One digester developer (Simon Kitching) recommends suggests avoiding the xmlrules module and staying with the standard java API for configuring rules. No other recent digester developer has expressed any opinion on this subject.

Simon's reasons for avoiding xmlrules

While the xmlrules approach does indeed work, I'm just not convinced it brings much benefit. When I first met digester, I started using the xmlrules module because it seemed to be the "highest abstraction". But in fact I found that the xml being parsed and the java classes that are being created/populated are conceptually tightly coupled anyway. There just isn't much need to change the xml->class mapping unless the classes are being changed. And if the classes are being changed then it isn't really any more work to change a mapping defined as code than to change a mapping defined in an external rules file.

...

And there are some features you just can't access via xmlrules. One example is passing references to arbitrary java objects via the ObjectParamRule.

In addition, none of the original authors of the xmlrules module are still active in the project, so help with this module may not be as readily available as support for the plain Java API.

I can see xmlrules being useful in some situations. Maybe if writing some code-generation tool (eg from a UML diagram) then it may be easier to generate xmlrules definitions than calls to the digester API.

...

And one other thing: it is very easy to add custom Rule classes when using the API; it's somewhat more complex to do so when using xmlrules (though not impossible).

Parsing xml files in multiple languages

...