commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: [digester] using non URL'ed DTD's
Date Wed, 14 Nov 2001 18:07:06 GMT

On Wed, 14 Nov 2001, Tal Dayan wrote:

> Date: Wed, 14 Nov 2001 10:04:16 -0800
> From: Tal Dayan <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: RE: [digester] using non URL'ed  DTD's
> >
> > > Now, how do I abort the parsing and throw an exception if the validation
> > > (using the DTD) fails ? Currently the parsing just continues as usual so
> > > when the parsing ends, the application does not know if the XML
> > document was
> > > valid or not.
> > >
> >
> > Normally, Digester just logs the error messages and goes on.  If you want
> > it to abort the parse instead, you need to implement a SAX ErrorHandler
> > that actually throws exeptions from its methods, and then call
> > digester.setErrorHandler() before the parse to install it.
> Thanks. It worked as advertised. We abort the parsing by throwing an
> java.lang.Error from the
> Error Handler. Is this is the right way to do so ?

That works ... or you could throw a SAXException (or a subclass of it) if
you wanted the error to be more specific.  This would ultimately get
rethrown from digester.parse() back to the application, so you could
throw (for example) a SAXParseException that includes the location of the
actual error.

> Also, Digester prints the entire stack trace of the SAXParseException
> excpetion before it calls our handler, even when the debugging level is set
> to zero. We don't want to turn off the logging but the dump of the entire
> stack just to report a syntax error in the XML document is more than our
> users need.
> How about not logging or dumping the exception if it is passed to a
> customized handler anyway ? Or, we can have a flag when setting the handler
> to indicate if Digester should report the exceptions as well.

That makes sense.  In the mean time, you can always subclass and override.

> > > And next step, how can I check if the public ID of the DTD in the XML
> > > document was the expected one (for which we set a local
> > resolver using the
> > > register() method) ?
> > >
> >
> > In other words, you want to ensure that *only* one of your registered
> > public IDs is selected?  In the plans is a setEntityResolver() that will
> > work like setErrorHandler() does, and lets you install your own.  In the
> > mean time, you could subclass Digester and override the resolveEntity()
> > method.  If the first argument is registered, go ahead and call the
> > superclass resolveEntity() method; if it's not, throw an exception.
> We integrated Jeff's Doctype Changer in our Digester wrapper class and it
> works great. You can
> force any DTD that you want, even if there is not DOCTYPE at all. The DTD
> you force can be fixed,
> or based on the original DOCTYPE and you can also save the properties of the
> original DOCTYPE to verified that the user specified a valid DTD. This is
> kind of functionality that I would expect to find in the XML parsers
> themselves but I don't think they provide it.
> Tal


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

View raw message