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]
