Re: EntityResolver problem with Aelfred parser

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
>
>
>