commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From martin.coo...@tumbleweed.com
Subject Re: [digester] using non URL'ed DTD's
Date Wed, 14 Nov 2001 18:21:02 GMT
>From the Javadocs for java.lang.Error:

"An Error is a subclass of Throwable that indicates serious problems that a
reasonable application should not try to catch."

So, no, Error is not the right thing to throw, because presumably it's
something you want to catch and handle elsewhere in your app. You'll want to
throw an exception of a class derived from java.lang.Exception instead.

--
Martin Cooper


----- Original Message -----
From: "Tal Dayan" <tal@zapta.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Wednesday, November 14, 2001 10:04 AM
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 ?
>
> 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.
>
>
> > > 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
>
> >
> > > Thanks,
> > >
> > > Tal
> > >
> >
> > Craig
> >
> >
> > > > -----Original Message-----
> > > > From: Louis Tribble [mailto:louis.tribble@webgain.com]
> > > > Sent: Tuesday, November 13, 2001 8:19 PM
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [digester] using non URL'ed DTD's
> > > >
> > > >
> > > > > We are still not able to use a DTD for validation because our
> > > > DTD file has a
> > > > > path that
> > > > > is not acceptable by Digester and/or the underlying XML parser
> > > > (the URL is
> > > > > 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> > > > > everything).
> > > >
> > > > >From RFC 1738:
> > > > > A file URL takes the form:
> > > > >
> > > > >    file://<host>/<path>
> > > > >
> > > > > <snip>
> > > > > As a special case, <host> can be the string "localhost" or
the
> > > > empty string; this
> > > > > is interpreted as `the machine from which the URL is being
> > interpreted'.
> > > >
> > > > With two slashes, "d:" is a host name. With three slashes, the
> > > > URL should be interpreted
> > > > correctly. By the grace of many URL parsers, one slash sometimes
> > > > works too.
> > > >
> > > > Louis Tribble
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message