[jdom-interest] DOMBuilder

[Jason Hunter]

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

> parser.setFeature("http://apache.org/xml/features/continue-after-fatal-error",
> false);

This is better done with
builder.setErrorHandler(someHandlerThatContinues)

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

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

-jh-