Re: setEntityResolver(null)

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

That would only make sense if it should never be null, but the default
value is Null, so I have to agree with Elliott on that. All he wants
is the ability to reset to the initial value and behaviour, if I understand
him correctly.
 
> 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. 

What percentage of them? Is there a consistent pattern?
Most SAX implementation on top of Expat would allow Null.

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

It would make most sense to go back to the initial/default behaviour.
For non-resolving one can then install a NonResolvingEntityResolver,
unless that is already the default behaviour.

> 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).
 
I think your comments are sensible, but would require more changes
to the spec - i.e. disallowing Null for the initial value and pre-defining
a NonResolvingEntityResolver and DefaultEntityResolver, at least for
consistency reasons.

Karl


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