Andy Clark wrote: > > "K. Ari Krupnikov" wrote: > > > Why is it not possible? Is this your own document impl or > > > something else? > > > > It's my (and a few other people's) own. > > http://sourceforge.net/projects/dbdom > > Okay, now I'm getting the picture... > > If you have any ideas as to how to make your scenario (and > similar ones) feasible in the parser, that would be great. > Perhaps just setting the document factory impl instead of > the document impl?
1) add a constructor that takes a DOMImplementation argument and overload init() and reset(). In this case, http://apache.org/xml/properties/dom/document-class-name doesn't need to be set explicitly - it can be established at runtime, and probably isn't needed at all, since you can call a standard factory method instead of newInstance() 2) add a constructor that takes a Document argument and overload init() and reset(). This method would make sense in applications (such as DBDOM) where Document can have extra information - in our case, a unique name - and so cannot be created with a standard DOM method. The Document would be expected to have no child nodes. Although I don't think this should be enforced - it might provide a convenient way to incrementally build documents. Again, no need to use newInstance( and hence no need for a string class name. These two are obviously not mutually exclusive. If DOMImplementation or Document is null, use default xerces.dom.DocumentImpl 3) Catch the unchecked ClassCastException, or, better yet, check the class of the Attribute before casting it in startElement() (line 1078) in DOMParser, depending on which scenario (AttrImpl or other Attr) you think is the more likely - http://nagoya.apache.org/bugzilla/show_bug.cgi?id=832 I can patch DOMParser if there is interest in these solutions. It appers that changes would be limited to org.apache.xerces.parsers.DOMParser -- K. Ari Krupnikov DBDOM - bridging XML and relational databases http://www.iter.co.il
