I actually found the reason of this behavior : when you redefine
http://apache.org/xml/properties/dom/document-class-name, you lose everything
implemented in the DocumentImpl class (which is pretty normal) but also half of
what is
implemented inside the DOMParser since it's directly and explicitely using the
DocumentImpl class.
What I would like is to keep this code, at least in case you're just subclassing
DocumentImpl to change its behavior. This could be done by applying the
following
little patch to the parser :
Index: DOMParser.java
===================================================================
RCS file:
/home/cvspublic/xml-xerces/java/src/org/apache/xerces/parsers/DOMParser.java,v
retrieving revision 1.40
diff -5 -r1.40 DOMParser.java
911a912
> boolean
> isInstanceOfDocumentImpl =
Class.forName(DEFAULT_DOCUMENT_CLASS_NAME).isAssignableFrom(Class.forName(fDocumentClassName));
937a939,941
>
if (isInstanceOfDocumentImpl) {
>
fDocumentImpl = (DocumentImpl) fDocument;
>
}
Is it reasonnable ?
If yes, could someone commit it ?
Sebastien
[EMAIL PROTECTED] wrote:
> I'm having some problems with the
> http://apache.org/xml/properties/dom/document-class-name property of the DOM
> parser.
>
> Actually, when I set it to my own document implementation, which is an empty
> wrapper
> around the default one, the documents do not have a document type. The
> parsing seems
> however to be done correctly. Is it a bug in the default DocumentImpl
> implementation
> ?
>
> Sebastien
