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