DOMMemDebug

["KRAUSE,MIKE (HP-FtCollins,ex1)" <mi...@hp.com>]

Hi,

When I run purify on my code, I get several memory leaks from a class called
DOMMemDebug.  This resides in the xerces library.  Should this really be
built into the release version of the XML parser?

Regards,

Mike Krause
Hewlett-Packard Company

Re: setPrefix

[Arnaud Le Hors <le...@us.ibm.com>]

Boris Garbuzov wrote:
> 
>     data = "data";
>     CDATASectionImpl cDataSectionImpl = new CDATASectionImpl
> (documentImpl, data);
>     println ("NodeImpl's API");
>     NodeImpl nodeImpl = (NodeImpl) cDataSectionImpl;
> ...
>     prefix = "prefix";
>     nodeImpl.setPrefix (prefix);
> 
> ---------------
> Why last statement of the above code produces the following error?
> ----------------
> 
> org.apache.xerces.dom.DOMExceptionImpl: DOM003 Namespace error
> ...

Because namespaces in general only apply to elements and attributes. So
in the DOM only Element and Attr nodes can have a namespaceURI and a
(namespace) prefix. Trying to set a prefix on another type of node is an
error.
Otherwise, I have two other comments on your code (no offense):
First, a CDATASectionImpl inherits from NodeImpl, so the cast:

>     NodeImpl nodeImpl = (NodeImpl) cDataSectionImpl;

isn't necessary.
Second, unless you have a specific reason that isn't exposed in your
message, referring to *Impl classes all over the place like that isn't
necessary. Only a few things ("proprietary features") are only
accessible from the classes and require casting. Your sample would work
just using the standard interfaces:

>     data = "data";
>     CDATASection cDataSection = document.createCDATASection(data);
> 
>     String namespaceURI = cDataSection.getNamespaceURI();
>     println ("namespaceURI = " + namespaceURI);
> 
>     String prefix = cDataSection.getPrefix();
>     println ("prefix = " + prefix);
> 
>     // casting to access proprietary API
>     Object userData = ((NodeImpl)cDataSection).getUserData();
>     println ("userData = " + userData);
> 
>     prefix = "prefix";
>     cDataSection.setPrefix (prefix);

Hope this helps.
-- 
Arnaud  Le Hors - IBM Cupertino, XML Technology Group

setPrefix

[Boris Garbuzov <bo...@keystrokenet.com>]

    data = "data";
    CDATASectionImpl cDataSectionImpl = new CDATASectionImpl (documentImpl,
data);
    println ("NodeImpl's API");
    NodeImpl nodeImpl = (NodeImpl) cDataSectionImpl;

    String namespaceURI = nodeImpl.getNamespaceURI();
    println ("namespaceURI = " + namespaceURI);

    String prefix = nodeImpl.getPrefix();
    println ("prefix = " + prefix);

    Object userData = nodeImpl.getUserData();
    println ("userData = " + userData);

    prefix = "prefix";
    nodeImpl.setPrefix (prefix);

---------------
Why last statement of the above code produces the following error?
----------------

org.apache.xerces.dom.DOMExceptionImpl: DOM003 Namespace error
 at org.apache.xerces.dom.NodeImpl.setPrefix(NodeImpl.java:741)
 at com.keystrokenet.loanproduct.xml.test.Lab.executeTestBody(Lab.java:642)



--
Boris Garbuzov.
Mailing address:
Box 715, Seattle, Washington, 98111-0715, USA.
E-mail: garbuzov@hotmail.com, boris@keystroke.com.
Telephone: 1(206)781-5165 (home), 1(206)576-4549 (office).
Resedential address: 139 NW 104 Street, Seattle, 98177, Wa, USA

Re: DOMMemDebug

[Andy Heninger <he...@us.ibm.com>]

DOMMemDebug is a class that is used by the DOM test programs to check for
leaks resulting from problems with the reference counted memory management.

It's just a small amount of code, and it didn't seem worth the trouble to
set up the build to omit it from the release build.  Complicating the
picture a bit, we do build and run the tests on the release build also, and
without a DOMMemDebug implementation available, their build would fail.
DOMMemDebug is not used directly from the DOM implementation, but only from
the test programs.

There are a number of counters within the DOM implementation that
DOMMemDebug references.  It might be worth omitting the code that updates
these counters from the release builds, since it does run in the course of
normal DOM operation, and presumably takes some amount of time.  But in the
performance tests that I have run, while the updating of the reference
counts in the DOM is visible, the object instance counters - the ones used
by DOMMemDebug - don't show up as being significant.

It's not obvious to me why Purify would complain about DOMMemDebug leaking,
since it allocates no storage at all.

  -- Andy



From: "KRAUSE,MIKE (HP-FtCollins,ex1)" <mi...@hp.com>
>
> When I run purify on my code, I get several memory leaks from a class
called
> DOMMemDebug.  This resides in the xerces library.  Should this really be
> built into the release version of the XML parser?
>
>