Re: EntityResolver problem with Aelfred parser
Maarten Coene <[email protected]> Thu, 22 Apr 2004 10:44:17 +0200
| Newsgroups | gmane.comp.java.classpath.extensions.discuss |
|---|---|
| Organization | QMedit |
| Message-ID | <[email protected]> |
Hi, is there any chance this issue will be solved in the upcoming release? We have an application that does a lot of XML processing and we are using Xerces as parser. I would like to give the gnu jaxp parser a try, but I can't because of this issue. The problem is we are using DTD's that are not accessible through an URL or through the filesystem (that's why there is a custom EntityResolver registered with the parser). regards, Maarten Maarten Coene wrote: > I'm not saying that the Aelfred parser should guess how to resolve the > entity, all I'm saying is that *if the application has registered an > EntityResolver*, the parser should *first* ask this EntityResolver to > resolve the entity. If this EntityResolver can't resolve it, the > parser should use it's default strategy (using the base URI or > whatever) to resolve the entity (in my example: throw an exception > like Aelfred does now). > > There are situations where providing a base URI is not appropriate. > For instance: suppose I have stored the DTD files into a database, > what should I specifiy as base URI ? Or what if I have hard-coded the > DTD declaration as a String in my custom EntityResolver (e.g. to > improve performance). > > I also think this is what the EntityResolver.resolveEntity(...) > javadoc says ... > > Maarten > > David Brownell wrote: > >> Maarten Coene wrote: >> >>> Hi, >>> >>> I have a problem with specifying an EntityResolver with the Aelfred >>> SAXDriver. In some situations, the specified EntityResolver will not >>> be used to resolve the entities. This can happen if you pass an >>> InputSource to the SAXDriver.parse( ... ) method without specifying >>> a systemId. >> >> >> >> Passing such an InputSource is a bug in your application level >> code. Provide a base URI, and all SAX parsers should act the >> same. If you don't, there's no way to guess the right value; >> and I don't know any "how to guess" convention that can won't >> break in some environments. (For a file, it might be $PWD. >> For an HTTP URI, it might be something else entirely ...) >> Which is why it doesn't guess, and reports that error. >> >> If you really really want to make it harder to notice that kind >> of application bug, don't just hide that guess ... make it an >> explicit thing, at least by way of a "here's where we guess" >> comment. A settable parser property for the default value >> would is the best option I've heard. >> >> - Dave >> >> >> > > > > _______________________________________________ > Classpathx-discuss mailing list > [email protected] > http://mail.gnu.org/mailman/listinfo/classpathx-discuss