jhunter at collab.net
Tue Mar 6 12:29:18 PST 2001
> I'm not sure what the difference is between these two, but here are the
> features we're setting on the Xerces DOM parser:
> parser.setFeature("http://xml.org/sax/features/validation", false);
This is better done with builder.setValidation(false)
This is better done with
> parser.setFeature("http://apache.org/xml/features/allow-java-encodings", true);
This is is only supported on Xerces.
> Yup, I know... The problem is that there's no way to distinguish features that
> are pretty well guaranteed to be JDOM-safe, now and forever (e.g.
> allow-java-encodings) from those that are iffy (e.g. will
> continue-after-fatal-error cause problems? dunno.) from those that will
> definitely screw up JDOM (e.g. namespace features).
Yep. That's the core of issue. You basically blow away all
encapsulation and expose the internals.
> > BTW, remember you can write whatever builder you want. We
> > just provide two by default.
> Yup. If this doesn't get changed in JDOM, I'm going to have to go this route.
> That's annoying (to have to subclass the builder just to set a parser feature).
That'd be the easiest solution. Subclass and have the subclass expose
> But I'm much more concerned about people using DOMBuilder instead, as other
> people in my group have done, rather than taking the route you suggest. It is a
> terrible waste if we unintentionally encourage people to use DOMBuilder rather
> than SAXBuilder, just so they can turn on "allow-java-encodings", for example.
> I would solve this problem by listing the common features/properties that are
> expected to always be safe, and the ones that are known to be unsafe (or are
> likely to be unsafe in the future). All others are use-at-your-own-risk. The
> SAXBuilder that takes an XMLReader (or that has setProperty and setFeature)
> could be a subclass of the regular SAXBuilder, if that would emphasize the
> issue. It's simply a matter of what you think is the lesser of two evils.
What do others think?
> In any case, I think SAXBuilder should have a protected getParser() method so
> that this is possible to do via a subclass, rather than having to write a whole
> new implementation.
Makes sense. Care to submit a patch?
More information about the jdom-interest