Re: setEntityResolver(null)

Elliotte Rusty Harold wrote,
> It has previously been my understanding that you can remove an
> EntityResolver, and the various other listeners set on a XMLReader by
> passing null to the appropriate setter method such as
> setEntityResolver. The SAX API documentation does not justify this,
> but it doesn't say it's prohibited either. See
<snip/>

It's always been my understanding that the argument to setEntityResolver 
should be non-null: it's strongly suggested by "Applications may 
register a *new* or *different* resolver" ... tho' I agree that this 
could just about be stretched to cover null as well.

On the whole I think that the elaboration in the J2SE version of the SAX 
javadoc is reasonable.

> I am requesting discussion and official resolution of whether or not
> its acceptable to pass null to setEntityResolver to remove any
> currently installed EntityResolver. Personally, since there's no
> other way to remove an EntityResolver without providing a new one, I
> think this is necessary.
<snip/>

Not so.

It'd be quite possible to define NonResolvingEntityResolver and/or 
DefaultEntityResolver implementors of the EntityResolver{2} interface 
with the obvious semantics and have applications pass instances of 
those to setEntityResolver. I think the question would then be whether 
or not those implementations should be part of the standard SAX 
distribution. 

I don't like the idea of using null for this job for a couple of 
reasons. First, it breaks existing implementations, as you've observed. 
Second, it's not immediately clear whether it's supposed to mean "Never 
resolve external entities" or "Resolve external entities in the default 
way" ... I couldn't work out which behaviour you were expecting from 
the description in your post.

Of course, this could be specified in the javadoc for setEntityResolver, 
but I think that even then the interface would be confusion prone. 
Given the security issues that the default entity resolution policy can 
have in some applications, I think any such confusion should be avoided 
if possible. Using instances of EntityResolver{2} implementors that 
have descriptive names along the lines of NonResolvingEntityResolver 
and DefaultEntityResolver helps here. It also provides a convenient and 
very visible place in the javadoc to discuss the semantics and their 
implications (ie. the class-level javadoc for each of the 
implementating classes rather than the method-level javadoc for 
setEntityResolver).

Cheers,


Miles


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
List: sax-devel, [email protected]
See:  http://www.saxproject.org/
https://lists.sourceforge.net/lists/listinfo/sax-devel