RE: [jira] Commented: (XERCESC-1360) compile error for 64bit solaris binary by GCC 3.3.2

Hi thanks. In Makefile.incl we removed all occurrences of next line: -L/usr/local/lib We have older GCC(default) still there. It has all libstdc++ installed there and libstdc++.so -> libstdc++.so.5.0.1 linked to 5.0.1. That what gave trouble. warm regards Saurabh [EMAIL PROTECTED] 08/10/2

[jira] Created: (XERCESC-1473) DOMElement::setAttributeNS needlessly creates DOMAttr if a qualified name is used

DOMElement::setAttributeNS needlessly creates DOMAttr if a qualified name is used - Key: XERCESC-1473 URL: http://issues.apache.org/jira/browse/XERCESC-1473 Project: Xerces-C++ Type: Imp

DOM documents chew up 64k each?

Maybe this is sort of well-understood by people, but I was rather surprised to find that every single DOM document I create and hold is reserving 64k blocks right off the bat due to the size of the kHeapAllocSize constant inside DOMDocumentImpl.cpp I couldn't figure out why I was losing so much RA

[jira] Resolved: (XERCESC-1400) DOMWriter::writeNode throws DOMSystemException, but this class doesnt exists

[ http://issues.apache.org/jira/browse/XERCESC-1400?page=all ] cargilld resolved XERCESC-1400: --- Resolution: Fixed Hi, I removed the references to DOMSystemException in the 2.7 and 3.0 branches in svn. David > DOMWriter::writeNode throws DOMSystemEx

RE: [jira] Commented: (XERCESC-1360) compile error for 64bit sola ris binary by GCC 3.3.2

It works fine with GCC 3.4.3 and 4.0.0. Also, GCC on Solaris is not supported to begin with. Whoever needed this fixed should probably check the fixed bug logs for GCC and see if this was addressed. I imagine it must have been. I seriously doubt this is Xerces' fault. HTH, Matt -Original Mess

[jira] Resolved: (XERCESC-1169) Just a suggestion for the class DOMException

[ http://issues.apache.org/jira/browse/XERCESC-1169?page=all ] Alberto Massari resolved XERCESC-1169: -- Fix Version: 2.6.0 Resolution: Fixed Assign To: (was: Xerces-C Developers Mailing List) It looks getMessage has been added ove

[jira] Resolved: (XERCESC-974) Base64::decode whitespace

[ http://issues.apache.org/jira/browse/XERCESC-974?page=all ] Alberto Massari resolved XERCESC-974: - Resolution: Fixed Assign To: (was: Xerces-C Developers Mailing List) Base64 data uses whitespace only as a formatting, not to represent

Apachecon talk

Hey all, Sorry for the cross post, but I want to get as much input as possible. We had a PMC phone call a couple of days ago and we decided it would be good if we went to Apache con and did a talk. We are now a TLP and should participate as much as possible tin these things. It will be valua

Re: memory leak with getElementsByTagName()

Hi, Ram wrote: Hi Jesse, Actually I have posted this only after going through the archives. That discussion was not conclusive. There has been some related discussion. I summarized it in a blog entry: http://blog.parthenoncomputing.com/xerces/archives/2005/05/memory_manageme.html My Questi

[jira] Resolved: (XERCESC-1289) Xerces-c++ version 2.60 crashes.

[ http://issues.apache.org/jira/browse/XERCESC-1289?page=all ] cargilld resolved XERCESC-1289: --- Resolution: Fixed Closing, since no response to provide additional information required. David > Xerces-c++ version 2.60 crashes. > --

[jira] Resolved: (XERCESC-1292) multiple occurance of same attributes in Attributes

[ http://issues.apache.org/jira/browse/XERCESC-1292?page=all ] cargilld resolved XERCESC-1292: --- Resolution: Fixed Closing, since no response to provide additional information required. David > multiple occurance of same attributes in Attributes > ---

[jira] Updated: (XERCESC-769) RFE: Xerces-C++ modularization - config for smaller builds/remove features

[ http://issues.apache.org/jira/browse/XERCESC-769?page=all ] Alberto Massari updated XERCESC-769: Bugzilla Id: (was: 15785) type: Improvement (was: Bug) Description: The Xerces-C++ documentation briefly mentions that Xerces is "mod

[jira] Resolved: (XERCESC-1341) Gives IOT/Abort (core dump)

[ http://issues.apache.org/jira/browse/XERCESC-1341?page=all ] cargilld resolved XERCESC-1341: --- Resolution: Incomplete Closing, since no response to provide additional information required. David > Gives IOT/Abort (core dump) > --

[jira] Commented: (XERCESC-1360) compile error for 64bit solaris binary by GCC 3.3.2

[ http://issues.apache.org/jira/browse/XERCESC-1360?page=comments#action_12318305 ] cargilld commented on XERCESC-1360: --- Hi, Is this still a problem or can we close this bug? BTW, the error sounds like a compiler error, so maybe it is a problem with g

[jira] Commented: (XERCESC-1368) Catch-all handler are problematic on Windows

[ http://issues.apache.org/jira/browse/XERCESC-1368?page=comments#action_12318304 ] cargilld commented on XERCESC-1368: --- Hi Dave, Do you have more patches coming for this bug or should we close it? Thanks, David > Catch-all handler are problematic on W

[jira] Resolved: (XERCESC-1439) 3.0-unstable: make output improved (pretty-print)

[ http://issues.apache.org/jira/browse/XERCESC-1439?page=all ] Alberto Massari resolved XERCESC-1439: -- Resolution: Duplicate Duplicate of XERCESC-1440 > 3.0-unstable: make output improved (pretty-print) > --

RE: memory leak with getElementsByTagName()

Hi Jesse, Actually I have posted this only after going through the archives. That discussion was not conclusive. My Question is : a)If we search for non-existent entries in a file why the memory is increased using getElementsByTagName() ? (I may not have the liberty to release the document everyt

[jira] Commented: (XERCESC-1468) Wrong encoding in output

[ http://issues.apache.org/jira/browse/XERCESC-1468?page=comments#action_12318274 ] Manfred Egger commented on XERCESC-1468: OK, I see. Solved this Issue with a MemBufFormatTarget > Wrong encoding in output > > > K