[jdom-interest] SAX Parsers

[David W. Smiley]

Brett McLaughlin wrote:
...
> >         My point is that I wanted to use JDom without the Xerces library and I
> > was unsuccessful.  I understand, of course, that I'll need a parser;
> > it's just that I wanted to use another parser (Sun's) without having the
> > Xerces library around because JDom uses a few classes here and there in
> > Xerces.  This is not absolutely necessary, but I think JDom should not
> > tie itself to Xerces.  Is this recognized as a problem, and if so, what
> > is the solution?
> 
> It isn't a problem, because it doesn't use Xerces specific classes,
> ever, except through reflection. You can plug in Project X, and if it
> has the SAX classes, you are ready to go.

ProjectX is not SAX2, so I am not ready to go.  I basically had to wrap
it in a dummy "Parser" class that came with SAX2 for bridging to SAX1
APIs to SAX2.
I thought that I could use ProjectX (implicitly through the default
behavior of JAXP) going through SAXBuilder.  I chose SAXBuilder as
opposed to DOMBuilder because (1) I figure it is more efficient since it
would not go through the org.w3c.dom layer, and (2) I needed to disable
external entity resolving which is a SAX concept
	[sorry if that paragraph is confusing, try reading slower]
So, if I want to use JDom's SAXBuilder with ProjectX without Xerces with
SAX2 and disable external entity resolving, I can't.  This is my grand
problem.  Since it looks like this won't be surmountable any time soon I
guess I'll go with Xerces.

> >
> > > No - that requires users to know more than they need to about SAX, we
> > > had decided.
> >
> > In my case I NEED to know about SAX because the default SAX handling
> > does not handle external entities the way I want it to.  I claim that if
> > the constructor I proposed is added, users will still not need to know
> > about SAX since they won't use that constructor.
> >
> > >Setting an entity resolver, however, is something we will
> > > let you do, so that solves your problem nicely. We'll also let you set
> > > an Error Handler.
> >
> > How will you let me do it then?  I would /really/ prefer my proposed
> > constructor instead of having the JDom API deal with concepts such as
> > entity resolvers.
> 
> We don't want to let the user pass in an XMLReader because we lose an
> enormous amount of ability to control the output, which is what
> guarantees that JDOM behaves.

Bummer, ah well.  Maybe you could configure the XMLReader passed in?

>If all you are doing is setting the entity
> resolver, what is so bad about setEntityResolver() in SAXBuilder?

Okay.  So where is this mystery method?  It is not in my distribution of
JDom.

THANKS for these prompt responses.

-- David Smiley
   The MITRE Corporation