You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announcements@xml.apache.org by Tinny Ng <tn...@ca.ibm.com> on 2003/02/07 14:20:02 UTC

[ANNOUCEMENT] Xerces-C++ 2.2.0 is ready

Hi Everyone,

The release Xerces C++ 2.2.0 is now ready.

Highlights of this version:

 - C++ Namespace Support
 - Schema 1.0 Errata Implementation
 - Experimental Implementation of XML 1.1
 - More DOM L3 Core Support:
       - baseURI, isId, getTypeInfo, setIdAttribute, setIdAttributeNS, setIdAttributeNode
 - RPM for Linux
 - 390: Uniconv390 support
 - 390: support record-oriented MVS datasets with the DOM Level 3 serialization APIs
 - Support for Linux/390
 - Performance: Break Scanner for different functionalities and many other performance improvement
 - plus many more minor items and bug fixes

This is a source and binary (32 bit/64bit: AIX, HP11, Linux, Solaris, Windows) release.

You may download it from http://xml.apache.org/dist/xerces-c/stable/

See http://xml.apache.org/xerces-c/index.html for details.

Regards,

Tinny Ng
XML Parsers Development
IBM Toronto Laboratory, email: tng-xml@ca.ibm.com


Re: [ANNOUCEMENT] Xerces-C++ 2.2.0 is ready

Posted by Guillaume Morin <gu...@morinfr.org>.
Dans un message du 07 Feb à  8:20, Tinny Ng écrivait :
> The release Xerces C++ 2.2.0 is now ready.
(snip)

I do not see any mentions of the ability to build a static library. It
was supposed to be included in this release : 

http://marc.theaimsgroup.com/?l=xerces-c-dev&m=102941246017830&w=2

The bug (#11237) has not even been updated although there are two
patches provided.

Any explanations ?

Again, if you cannot keep the ABI stable, you should provide a way to
build a static library. There are currently 3 xerces-c versions in
Debian because we cannot build a static version and this is _really_ a
PITA.

-- 
Guillaume Morin <gu...@morinfr.org>

   I'm unclean, a libertine, every time you vent your spleen, I seem to lose
    the power of speech, you're slipping slowly from my reach, you grow me
        like an evergreen, you've never seen me lonely at all. (Placebo)

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org


Memoryleak, DOMDocument forgets to delete doctypeNode.

Posted by Erik Rydgren <er...@mandarinen.se>.
Hi all!

I am in the process of wrapping my project up (read: hunting down bugs by
the million) and I found a memoryleak which for once isn't my fault *GLEE*.
I use Xerces DOM in the following way (disregard case on method names and
such. It really is a one to one mapping):

	cDocumentType* poDocumentType =
GetDOMImplementation().CreateDocumentType("reply", "", "RPC.DTD");
	cDocument* m_poDocument = GetDOMImplementation().CreateDocument("",
"reply", poDocumentType);
      // usage of document here
	delete m_poDocument;

The root of the problem is that the doctype is allocated outside of the heap
that the document controls. Hence, it doesn't get deleted.
The release() method of the document takes care of it but release() is not
called when you delete a document directly like this.
My suggestion is to avoid the whole problem alltogether by never linking a
doctypenode allocated outside of the documentheap into the document in the
first place.

Like this:

void DOMDocumentImpl::setDocumentType(DOMDocumentType *doctype)
{
    if (!doctype)
        return;

    // New doctypes can be created either with the factory methods on
DOMImplementation, in
    //   which case ownerDocument will be 0, or with methods on
DocumentImpl, in which case
    //   ownerDocument will be set, but the DocType won't yet be a child of
the document.
    if (doctype->getOwnerDocument() != 0 && doctype->getOwnerDocument() !=
this)
        throw DOMException(    //one doctype can belong to only one
DOMDocumentImpl
        DOMException::WRONG_DOCUMENT_ERR, 0);

    // If the doctype is not already owned by us then it was created on a
heap outside
    // Clone it into our heap instead and then discard the old object
    if (doctype->getOwnerDocument() != this) {
      DOMDocumentType *tmpdoctype = doctype;
      doctype = createDocumentType(doctype->getName(),
doctype->getPublicId(), doctype->getSystemId());
      delete tmpdoctype;
    }

    // The doctype can not have any Entities or Notations yet, because they
can not
    //   be created except through factory methods on a document.

    // revisit.  What if this doctype is already a child of the document?
    appendChild(doctype);
}

It is a small performance hit but then you can throw away all reference
checking in the release function instead.
Those who need brutal performance can still use the
DOMDocumentImpl::createDocumentType() - DOMDocumentImpl::setDocumentType()
combo.
Suggestions? Flames? Anyone who want to send me the biggest fryingpan in the
cupboard to swat bugs with?

Regards

Erik Rydgren
Mandarinen systems AB
Sweden


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org