commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: [Digester] Unable to get validation working
Date Tue, 26 Apr 2005 13:32:11 GMT
On Tue, April 26, 2005 2:22 am, Simon Kitching said:
> Yep. All XML document declarations really should have a PUBLIC
> identifier. Ones that have only a system identifier are extremely
> "fragile" in that they expect the machine they are processed on to have
> the dtd available in a specific place.
> The whole purpose of the PUBLIC identifier is to be able to redirect
> requests for the associated dtd to some arbitrary file, in exactly the
> way you want to do via the "Digester.register(publicId, URL)" method.

This is the part that confused me in the end the most... so then it would
be correct to say that the location specified in the DOCTYPE declaration
is overridden by what you specify with the call to register(), correct? 
If so, that's the point I didn't realize (and frankly just guessed at in
the end to solve this)... that's why specifying public didn't seem right
to me in the first place, I figured the location had to be valid, which
wouldn't be the case here.

> And as Craig says, the public ID really should be a much longer and much
> more unique string than just "myConfig", so that software that deals
> with many different xml document types can tell them apart. However if
> this particular document is only expected to be fed into pieces of
> software that deal with just this document type then you can get away
> with this.

I see... in this case this document would only be read by a Struts plugin,
so yeah, I should be able to get away with it.  I think I'll just go make
it longer none the less, no harm no foul :)

> By the way, if you get confused you can always avoid Digester's
> validation support and set things up the traditional way, ie you can
> always do
>   digester.setValidating(true);
>   SAXParser parser = digester.getParser();
> then call the SAXParser methods directly to configure validation (in
> particular, setting a custom EntityResolver via
> parser.setEntityResolver). This won't bother the digester at all;
> digester really doesn't care much about validation as that occurs within
> the parser before events are passed to Digester.

The problem is, I've never before had a need to validate a document before
parsing, I've always just gone directly to parsing (kind of odd that that
would be true now that I say it, but it is!).  So, my experience wasn't
quite up to this in this case :)

> One other thing you should watch out for when enabling validation: by
> default, Digester will ignore errors reported by the parser (other than
> logging them). You will need to register a custom error handler in order
> to take appropriate action when an error occurs (which probably just
> means throwing the parameter object as an exception):
>    digester.setErrorHandler(myCustomErrorHandler)
> or
>    digester.getParser().setErrorHandler(myCustomErrorHandler)
> The only difference between these two is that the first allows Digester
> to log a message before forwarding to your custom errorhandler.

Cool.  I did notice that execution happily continued when a parse error
occurred (until something that needed the results of the parsed document
tried to execute of course).  I appreciate that heads-up, as well as the
rest of your explanation here Simon, it was all very helpful (as was Wendy
and Craig's responses) :)


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

View raw message