Re: setEntityResolver(null)

Miles Sabin <[email protected]> Wed, 2 Apr 2003 15:00:03 +0100
Newsgroups gmane.text.xml.sax.devel
Message-ID <[email protected]>
Karl Waclawek wrote,
> 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 think the default value _is_ null. The default is what you get 
when setEntityResolver isn't invoked at all. It's possible that 
internally an implementation might have a field which is null in this 
case, but that's an implementation detail.

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

Well, at some point the JAXP spec acquired a "throws 
NullPointerException" clause on setEntityResolver, and that's reflected 
in the the current J2SE Javadoc, and presumably in the current J2SE 
implementation. So that accounts for a significant percentage.

To be perfectly honest I'm not sure if JAXP did something wrong here or 
if the original SAX2 spec specified the throws clause and it was 
removed retrospectively. Some of the comments in this thread suggest 
the latter, and that jibes with my (quite possibly mistaken) 
recollection that there was always a presumption against nulls even if 
it wasn't properly documented or consistently enforced.

Whatever, JAXP 1.3 (aka JSR-206 [1]) is just about to kick off, so now 
would be a *very* good time to try and sort this out.

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

Actually, my proposal doesn't require any changes to the spec beyond the 
reinstatement of the throws clause. It'd be desirable, but absolutely 
_not_ necessary to provide implementations of the two resolvers as part 
of the SAX distribution, because they can both be defined by end users.

Cheers,


Miles

[1] http://www.jcp.org/en/jsr/detail?id=206


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