Thank you for your answer. I'll file a bug report on this.
Regards, Patrick
-----Original Message----- From: Elena Litani [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 4:58 PM To: [EMAIL PROTECTED] Subject: Re: Fw: Inconsistency when providing own DocumentImpl?
Hi Patrick,
There is indeed a bug in PSVIDocumentImpl. I just glanced through the code
and the PSVIDocumentImpl should AT LEAST override cloneNode(),
importNode() methods and it might need to modify adoptNode().
I suggest you file a bug report against the latest Xerces release. Patches
are always welcome :)
Thank you, ---- Elena Litani / IBM Toronto
Patrick Decker
<[EMAIL PROTECTED]>
To
03/17/2004 04:21 [EMAIL PROTECTED]
AM cc
Subject Please respond to Fw: Inconsistency when providing xerces-j-dev own DocumentImpl?
Hi,
A few days ago I posted below issue. Is there any expert on the list who can answer me?
Regards, Patrick
On Wed, 10 Mar 2004 16:09:37 +0100, Patrick Decker <[EMAIL PROTECTED]> wrote:
Hi,
When replacing the document implementation of Xerces via the DOMParser property "http://apache.org/xml/properties/dom/document-class-name";, I think I have found an inconsisteny in Xerces DOM implementation. The iconsistency I believe to have found as such is: the replaced document implementation is not always returned.
In AbstractDOMParser, there's code how I expect this to work:
if (fDocumentClassName.equals (DEFAULT_DOCUMENT_CLASS_NAME)) {
fDocument = new DocumentImpl ();
...
}
else {
// use specified document class
...
But there are two classes, which don't check for a specified document: DocumentImpl and DOMImplementationImpl.
In DocumentImpl's cloneNode() method, there's this line of code:
DocumentImpl newdoc = new DocumentImpl();
and no check for specified classes.
In DOMImplementationImpl's createDocument() method, the behaviour is similar.
I have also checked out the PSVI document creation, since it gets activated in the same way (setting the property). I see in PSVIDOMImplementationImpl that it overrides createDocument, so that PSVIDocumentImpl is returned, but the problem for cloneNode still remains, since this method is not overridden. I can't imagine this is intended. But that's why I ask :)
So, is this a bug? If yes, where is the bug, in DocumentImpl and DOMImplementationImpl or in the replaced PSVIDocumentImpl and PSVIDOMImplementationImpl?
Are the new XYZDocumentImpl and related classes responsible for returning the correct DocumentImpl? Or shouldn't this be considered in DocumentImpl and DOMImplementationImpl (i.e. implement it there like AbstractDOMParser does)?
Regards, Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
