commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: Digester: No rules found matching
Date Sat, 05 Jun 2004 00:37:18 GMT
On Sat, 2004-06-05 at 04:31, Steve Fischer wrote:
> Hello-
> I am new to Digester.   I am using it for a simple application.
> I would like digester to halt if the XML file contains unexpected tags 
> or attributes.   By unexpected I mean that there is no rule matching 
> them.   In other words, the file must only contain XML that conforms to 
> my rules.
> But, Digester continues past these, and only mentions the problem in the 
> log under DEBUG mode.
> Questions:
>    - can i make digester stop on a no-rule-found condition?   (if not, 
> what is the thinking behind why that is not an option?)
>    - or, do i need to define a DTD for my xml and use validation?   If 
> so, what errorHandler should I use?

Hi Steve,

This is definitely a case of "synchronicity"

I was trying to achieve exactly this effect just yesterday.

In the CVS HEAD version of digester, there is a Rules class called
"WithDefaultsRulesWrapper" which allows a set of default rules to be
returned if an element is encountered in the input and there are no
matching rules. By setting the default rule to be a rule that just
throws an exception from its "begin" method the effect we are trying to
achieve can be implemented. I got this working yesterday.

This WithDefaultsRulesWrapper class should work fine with the
digester-1.5 distribution, so if you don't want to use a complete
digester build from CVS you could still extract this class, change the
package name, and include it with your app.

I think that this solution could be made a bit more elegant though. I am
looking into whether the WithDefaultsRulesWrapper functionality could
essentially be embedded into the standard RulesBase class. And adding
this custom rule which throws exceptions into the standard Digester

Alternatively, a schema could be applied to the input as you mention.
I think you will need to call the Digester.setErrorHandler method with
an appropriate parameter in order to cause validation errors to
terminate processing.

Or, as you suggest, a flag could be added to the Digester to specify
whether processing should terminate if no match is found. I think this
is not a bad idea. You could of course implement this right now simply
by subclassing digester and overriding the startElement method. I
believe that this could be done quite elegantly by calling the inherited
startElement method, then inspecting the top object on the "matches"
stack; if it is null or an empty list then the current input element
matched no rules. [NB: not tested...]

If you have any other suggestions about how this could be implemented,
please let me know....



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message