From xerces-garciaoscar@example.com Mon Oct 01 08:11:43 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 40436 invoked by uid 500); 1 Oct 2001 08:11:43 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 40420 invoked from network); 1 Oct 2001 08:11:43 -0000 Message-ID: <garciaoscar@example.com> Date: Mon, 01 Oct 2001 10:12:23 +0200 From: Adib Taraben <garciaoscar@example.com> X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,de MIME-Version: 1.0 To: garciaoscar@example.com Subject: Re: PATCH: Base64 class References: <garciaoscar@example.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Ahoi Petr, could you please send me your complete source? Thanx, Adib. -- Adib Taraben garciaoscar@example.com WIGE DATA Tel: 5199923229 Wiesenring 11 Fax: 5199923229 LEIPZIG mail: garciaoscar@example.com GERMANY WWW: www.wige-data.de Petr Gotthard wrote: > > Hello world, > > please find attached patches for Base64 class, that provides > several improvements. > > The main change is new method "Bas888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4encode" for encoding > binary data and some new private data members. > In coherence with these changes, it was necessary to rename some > existing private data members and some variables, because their > original names can lead to misunderstanding. > Due to new data members, initialization method "Bas888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4init() was > also "a little bit" improved. > > Moreover, in the method "Bas888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4decode" was the call of > "XMLString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4trim()" replaced by other code. Method "trim()" > removes only leading and trailing whitespaces, but according to > RFC 2045 was necessary to remove _all_ whitespaces from the string. > > I would be glad, if you apply these patches to an original code. > > Regards, > > Petr > > ------------------------------------------------------------------------ > Name: Base64.cpp.patch > Base64.cpp.patch Type: unspecified type (application/octet-stream) > Encoding: quoted-printable > > Name: Base64.hpp.patch > Base64.hpp.patch Type: unspecified type (application/octet-stream) > Encoding: quoted-printable > > ------------------------------------------------------------------------ > --------------------------------------------------------------------- > To unsubscribe, e-mail: garciaoscar@example.com > For additional commands, e-mail: garciaoscar@example.com --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 09:13:48 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 81988 invoked by uid 500); 1 Oct 2001 09:13:46 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 81964 invoked from network); 1 Oct 2001 09:13:45 -0000 Date: 1 Oct 2001 09:13:58 -0000 Message-ID: <garciaoscar@example.com> From: garciaoscar@example.com To: garciaoscar@example.com Cc: Subject: DO NOT REPLY [Bug 3894] New: - File Iconv390TransService.hpp and .cpp not updated for two way transcoding support. X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3894>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3894 File Iconv390TransService.hpp and .cpp not updated for two way transcoding support. Summary: File Iconv390TransService.hpp and .cpp not updated for two way transcoding support. Product: Xerces-C++ Version: 1.4 Platform: Other OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: Utilities AssignedTo: garciaoscar@example.com ReportedBy: garciaoscar@example.com File Iconv390TransService.hpp and .cpp not updated for two way transcoding support. Result: class Iconv390Transcoder stays abstact and therefor can't be used. --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 10:51:18 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 68349 invoked by uid 500); 1 Oct 2001 10:51:17 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 68332 invoked from network); 1 Oct 2001 10:51:16 -0000 From: "Evert Haasdijk" <garciaoscar@example.com> To: <garciaoscar@example.com> Subject: RE: Serialize DOM_Node Date: Mon, 1 Oct 2001 12:51:13 +0200 Message-ID: <garciaoscar@example.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C14A77.C095F020" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <garciaoscar@example.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------=_NextPart_000_0000_01C14A77.C095F020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Try this... > -----Original Message----- > From: Paul Tan [mailto:garciaoscar@example.com] > Sent: Monday, October 01, 2001 5:24 AM > To: garciaoscar@example.com > Subject: Serialize DOM_Node > > > Hi, > > is there any way to serialise a DOM_Node (extract from the DOM > Tree) into a > string (or XMLCh) ? > > Thanks, > Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: garciaoscar@example.com > For additional commands, e-mail: garciaoscar@example.com > > > ------=_NextPart_000_0000_01C14A77.C095F020 Content-Type: application/octet-stream; name="DOMSerializer.hpp" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="DOMSerializer.hpp" //-----------------------------------------------------------------------= ---- // // File: DOMSerializer.h // Description: Class to serialize a DOM to a stream. Largely taken = from // the Xerces-c DOMPrint example // Works with Xerces-C 1.4 // // Rev: $Id: DOMSerializer.h,v 1.1 2001/04/05 13:04:39 = evert Exp $ // Created: 2001/03/30 // Author: Evert Haasdijk // mail: garciaoscar@example.com // //-----------------------------------------------------------------------= ---- #ifndef DOMSerializerH #define DOMSerializerH //-----------------------------------------------------------------------= ---- /* * 3. The end-user documentation included with the redistribution, * if any, must include the following acknowledgment: * "This product includes software developed by the * Apache Software Foundation (http://www.apache.org/)." * Alternately, this acknowledgment may appear in the software = itself, * if and wherever such third-party acknowledgments normally appear. * */ // = -------------------------------------------------------------------------= -- // Includes // = -------------------------------------------------------------------------= -- #include <util/PlatformUtils.hpp> #include <util/XMLString.hpp> #include <util/XMLUniDefs.hpp> #include <framework/XMLFormatter.hpp> #include <util/TranscodingException.hpp> #include <dom/DOM_DOMException.hpp> #include <dom/DOM.hpp> #include <dom/DOMString.hpp> #include <string> #include <ostream> #include <stdlib> // = -------------------------------------------------------------------------= -- /// XMLFormatTarget-derived class for use with the DOMSerializer. class DOMSerializerFormatTarget : public XMLFormatTarget { public: /** Constructor. @param os reference to the stream to write to. */ DOMSerializerFormatTarget(st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& os); /// Destructor ~DOMSerializerFormatTarget(); /// Implementations of the format target interface void writeChars(const XMLByte* const toWrite, const unsigned int count, XMLFormatter * const formatter); st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& stream(void); private: //@name: Unimplemented methods. //@{ /// copy constructor DOMSerializerFormatTarget(const DOMSerializerFormatTarget& other); /// assignement operator void operator=3D(const DOMSerializerFormatTarget& rhs); //@} /// reference to the stream to write to st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& os_; }; // = -------------------------------------------------------------------------= -- /** Serializes an in-memory DOM to a stream. */ class DOMSerializer { public: /// Default encoding for output - 'UTF-8' static const st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4string defaultEncoding_; /** Constructor. @param encoding const reference to a string denoting the encoding. Defaults to 'UTF-8'. */ DOMSerializer(const st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4string& encoding =3D defaultEncoding_); /// serialize the node and its descendants to the target void serialize(DOMSerializerFormatTarget* target, const DOM_Node& = node); private: /** Stream out a DOM node, and, recursively, all of its children. This function is the heart of writing a DOM tree out as XML source. = Give it a document node and it will do the whole thing. */ st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& doSerialize(st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& target, const DOM_Node& = toWrite); static const XMLCh gEndElement[]; static const XMLCh gEndPI[]; static const XMLCh gStartPI[]; static const XMLCh gXMLDecl1[]; static const XMLCh gXMLDecl2[]; static const XMLCh gXMLDecl3[]; static const XMLCh gXMLDecl4[]; static const XMLCh gStartCDATA[]; static const XMLCh gEndCDATA[]; static const XMLCh gStartComment[]; static const XMLCh gEndComment[]; static const XMLCh gStartDoctype[]; static const XMLCh gPublic[]; static const XMLCh gSystem[]; static const XMLCh gStartEntity[]; static const XMLCh gNotation[]; XMLFormatter* formatter_; st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4string encoding_; }; // = -------------------------------------------------------------------------= -- /** ostream << DOM_Node Serialize a DOM Node to stream s. Uses UTF-8 encoding. */ st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& operator<< (st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& s, const DOM_Node& node); // = -------------------------------------------------------------------------= -- /** ostream << DOMString Stream out a DOM string. Doing this requires that we first transcode to char * form in the default code page for the system. */ st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& operator<< (st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& target, const DOMString& s); XMLFormatter& operator<< (XMLFormatter& strm, const DOMString& s); #endif ------=_NextPart_000_0000_01C14A77.C095F020 Content-Type: application/octet-stream; name="DOMSerializer.cpp" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="DOMSerializer.cpp" //-----------------------------------------------------------------------= ---- // // File: DOMSerializer.cpp // Description: Class to serialize a DOM to a stream. Largely taken = from // the Xerces-c DOMPrint example. // Works with Xerces-C 1.4 // // Rev: $Id: DOMSerializer.cpp,v 1.1 2001/04/05 13:04:39 = evert Exp $ // Created: 2001/03/30 // Author: Evert Haasdijk // mail: garciaoscar@example.com // //-----------------------------------------------------------------------= ---- /* * 3. The end-user documentation included with the redistribution, * if any, must include the following acknowledgment: * "This product includes software developed by the * Apache Software Foundation (http://www.apache.org/)." * Alternately, this acknowledgment may appear in the software = itself, * if and wherever such third-party acknowledgments normally appear. * */ // = -------------------------------------------------------------------------= -- // Includes // = -------------------------------------------------------------------------= -- #include "DOMSerializer.hpp" #include <util/PlatformUtils.hpp> #include <util/XMLString.hpp> #include <util/XMLUniDefs.hpp> #include <framework/XMLFormatter.hpp> #include <util/TranscodingException.hpp> #include <dom/DOM_DOMException.hpp> #include <dom/DOM.hpp> #include <dom/DOMString.hpp> #include <string> #include <ostream> #include <stdlib> // = -------------------------------------------------------------------------= -- // DOMSerializerFormatTarget methods // = -------------------------------------------------------------------------= -- DOMSerializerFormatTarget888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4OMSerializerFormatTarget(st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& os) : os_(os) {}; DOMSerializerFormatTarget888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DOMSerializerFormatTarget() {}; void DOMSerializerFormatTarget888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4writeChars(const XMLByte* const toWrite, const unsigned int count, XMLFormatter * const formatter) { // Surprisingly, Solaris was the only platform on which // required the char* cast to print out the string correctly. // Without the cast, it was printing the pointer value in hex. // Quite annoying, considering every other platform printed // the string with the explicit cast to char* below. os_.write((char *) toWrite, (int) count); }; st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& DOMSerializerFormatTarget888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4stream(void) { return os_; }; // = -------------------------------------------------------------------------= -- // Static DOMSerializer members // // Note: This is the 'safe' way to do these strings. If you compiler = supports // L"" style strings, and portability is not a concern, you can = use // those types constants directly. // = -------------------------------------------------------------------------= -- const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gEndElement[] =3D // </ { chOpenAngle, chForwardSlash, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gEndPI[] =3D // ?> { chQuestion, chCloseAngle, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gStartPI[] =3D // <? { chOpenAngle, chQuestion, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gXMLDecl1[] =3D // <xml version=3D" { chOpenAngle, chQuestion, chLatin_x, chLatin_m, chLatin_l , chSpace, chLatin_v, chLatin_e, chLatin_r, chLatin_s, chLatin_i , chLatin_o, chLatin_n, chEqual, chDoubleQuote, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gXMLDecl2[] =3D // " encoding=3D" { chDoubleQuote, chSpace, chLatin_e, chLatin_n, chLatin_c , chLatin_o, chLatin_d, chLatin_i, chLatin_n, chLatin_g, chEqual , chDoubleQuote, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gXMLDecl3[] =3D // " standalone=3D" { chDoubleQuote, chSpace, chLatin_s, chLatin_t, chLatin_a , chLatin_n, chLatin_d, chLatin_a, chLatin_l, chLatin_o , chLatin_n, chLatin_e, chEqual, chDoubleQuote, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gXMLDecl4[] =3D // "?>\r\n { chDoubleQuote, chQuestion, chCloseAngle , chCR, chLF, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gStartCDATA[] =3D // <![CDATA[ { chOpenAngle, chBang, chOpenSquare, chLatin_C, chLatin_D, chLatin_A, chLatin_T, chLatin_A, chOpenSquare, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gEndCDATA[] =3D // ]]> { chCloseSquare, chCloseSquare, chCloseAngle, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gStartComment[] =3D // <!-- { chOpenAngle, chBang, chDash, chDash, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gEndComment[] =3D // --> { chDash, chDash, chCloseAngle, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gStartDoctype[] =3D // <!DOCTYPE { chOpenAngle, chBang, chLatin_D, chLatin_O, chLatin_C, chLatin_T, chLatin_Y, chLatin_P, chLatin_E, chSpace, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gPublic[] =3D // PUBLIC " { chLatin_P, chLatin_U, chLatin_B, chLatin_L, chLatin_I, chLatin_C, chSpace, chDoubleQuote, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gSystem[] =3D // SYSTEM " { chLatin_S, chLatin_Y, chLatin_S, chLatin_T, chLatin_E, chLatin_M, chSpace, chDoubleQuote, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gStartEntity[] =3D // <!ENTITY { chOpenAngle, chBang, chLatin_E, chLatin_N, chLatin_T, chLatin_I, chLatin_T, chLatin_Y, chSpace, chNull }; const XMLCh DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4gNotation[] =3D // NDATA " { chLatin_N, chLatin_D, chLatin_A, chLatin_T, chLatin_A, chSpace, chDoubleQuote, chNull }; const st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4string DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ultEncoding_( "UTF-8" ); // = -------------------------------------------------------------------------= -- // DOMSerializer member functions // = -------------------------------------------------------------------------= -- DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4OMSerializer(const st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4string& encoding) { encoding_ =3D encoding; formatter_ =3D 0; } void DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4serialize(DOMSerializerFormatTarget* target, const DOM_Node& node) { assert(target); // // convert encoding_ to XMLCh[] // DOMString encName =3D DOMString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4transcode( encoding_.c_str() ); formatter_ =3D new XMLFormatter(encName.rawBuffer(), target, XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes, XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4UnRep_CharRef); doSerialize(target->stream(), node); delete formatter_; formatter_ =3D 0; } st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& DOMSerializer888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4oSerialize( st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& target, const DOM_Node& toWrite) { // Get the name and value out for convenience DOMString nodeName =3D toWrite.getNodeName(); DOMString nodeValue =3D toWrite.getNodeValue(); unsigned long lent =3D nodeValue.length(); switch (toWrite.getNodeType()) { case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TEXT_NODE: { formatter_->formatBuf(nodeValue.rawBuffer(),=20 lent, XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4harEscapes); break; } case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4PROCESSING_INSTRUCTION_NODE : { *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gStartPI << = nodeName; if (lent > 0) { *formatter_ << chSpace << nodeValue; } *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gEndPI; break; } case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4DOCUMENT_NODE : { DOM_Node child =3D toWrite.getFirstChild(); while( child !=3D 0) { doSerialize(target, child); // target << child << st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4endl; child =3D child.getNextSibling(); } break; } case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ELEMENT_NODE : { // The name has to be representable without any escapes *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chOpenAngle << nodeName; // Output the element start tag. // Output any attributes on this element DOM_NamedNodeMap attributes =3D toWrite.getAttributes(); int attrCount =3D attributes.getLength(); for (int i =3D 0; i < attrCount; i++) { DOM_Node attribute =3D attributes.item(i); // // Again the name has to be completely representable. = But the // attribute can have refs and requires the attribute = style // escaping. // *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chSpace << attribute.getNodeName() << chEqual << chDoubleQuote << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ttrEscapes << attribute.getNodeValue() << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chDoubleQuote; } // // Test for the presence of children, which includes both // text content and nested elements. // DOM_Node child =3D toWrite.getFirstChild(); if (child !=3D 0) { // There are children. Close start-tag, and output = children. // No escapes are legal here *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chCloseAngle; while( child !=3D 0) { doSerialize(target, child); // target << child; child =3D child.getNextSibling(); } // // Done with children. Output the end tag. // *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gEndElement << nodeName << chCloseAngle; } else { // // There were no children. Output the short form close = of // the element start tag, making it an empty-element = tag. // *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chForwardSlash = << chCloseAngle; } break; } =20 =20 case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ENTITY_REFERENCE_NODE: { DOM_Node child; #if 0 for (child =3D toWrite.getFirstChild(); child !=3D 0; child =3D child.getNextSibling()) { doSerialize(target, child); // target << child; } #else // // Instead of printing the refernece tree=20 // we'd output the actual text as it appeared in the xml = file. // This would be the case when -e option was chosen // *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << = chAmpersand << nodeName << chSemiColon; #endif break; } =20 =20 case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4CDATA_SECTION_NODE: { *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gStartCDATA << nodeValue << gEndCDATA; break; } =20 case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4COMMENT_NODE: { *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gStartComment << nodeValue << gEndComment; break; } =20 case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4DOCUMENT_TYPE_NODE: { DOM_DocumentType doctype =3D (DOM_DocumentType &)toWrite;; *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gStartDoctype << nodeName; =20 DOMString id =3D doctype.getPublicId(); if (id !=3D 0) { *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chSpace << = gPublic << id << chDoubleQuote; id =3D doctype.getSystemId(); if (id !=3D 0) { *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chSpace=20 << chDoubleQuote << id << chDoubleQuote; } } else { id =3D doctype.getSystemId(); if (id !=3D 0) { *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chSpace << = gSystem << id << chDoubleQuote; } } =20 id =3D doctype.getInternalSubset();=20 if (id !=3D0) *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chOpenSquare << id << chCloseSquare; *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chCloseAngle; break; } =20 =20 case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ENTITY_NODE: { *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gStartEntity << nodeName; DOMString id =3D ((DOM_Entity &)toWrite).getPublicId(); if (id !=3D 0) *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gPublic << id << chDoubleQuote; id =3D ((DOM_Entity &)toWrite).getSystemId(); if (id !=3D 0) *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gSystem << id << chDoubleQuote; =20 id =3D ((DOM_Entity &)toWrite).getNotationName(); if (id !=3D 0) *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << gNotation << id << chDoubleQuote; *formatter_ << XMLFormatter888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4NoEscapes << chCloseAngle << = chCR << chLF; break; } =20 =20 case DOM_No888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4XML_DECL_NODE: { DOMString str; *formatter_ << gXMLDecl1 << ((DOM_XMLDecl = &)toWrite).getVersion(); *formatter_ << gXMLDecl2 << formatter_->getEncodingName(); =20 str =3D ((DOM_XMLDecl &)toWrite).getStandalone(); if (str !=3D 0) *formatter_ << gXMLDecl3 << str; =20 *formatter_ << gXMLDecl4; break; } default: { throw st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4runtime_error("Unrecognized node type"); // << (long)toWrite.getNodeType() << endl; } } return target; } // = -------------------------------------------------------------------------= -- // ostream << DOMString // = -------------------------------------------------------------------------= -- st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& operator<< (st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& target, const DOMString& s) { st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4auto_ptr<char> p( s.transcode() ); return target << p.get(); } // = -------------------------------------------------------------------------= -- XMLFormatter& operator<< (XMLFormatter& strm, const DOMString& s) { unsigned int lent =3D s.length(); if (lent =3D=3D 0) { return strm; } // else st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4auto_ptr<XMLCh> buf( new XMLCh[lent + 1] ); XMLString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4opyNString(buf.get(), s.rawBuffer(), lent); buf.get()[lent] =3D 0; return strm << buf.get(); } =20 // = -------------------------------------------------------------------------= -- st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& operator<< (st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ostream& s, const DOM_Node& node) { // // create serializer, use default encoding (UTF-8) // DOMSerializer serializer; // // assign s to format target // st888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4auto_ptr<DOMSerializerFormatTarget> target ( new = DOMSerializerFormatTarget(s) ); // // let the serializer do its thing // serializer.serialize(target.get(), node); return s; } ------=_NextPart_000_0000_01C14A77.C095F020 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com ------=_NextPart_000_0000_01C14A77.C095F020-- From xerces-garciaoscar@example.com Mon Oct 01 11:28:10 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 93378 invoked by uid 500); 1 Oct 2001 11:28:10 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 93367 invoked from network); 1 Oct 2001 11:28:09 -0000 Sender: desrefa Message-ID: <garciaoscar@example.com> Date: Mon, 01 Oct 2001 13:27:30 +0200 From: "Fabrice DESRE - FT.BD/FTRD/DMI/GRI" <garciaoscar@example.com> X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: xerces-c-dev <garciaoscar@example.com> Subject: DOM builing Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hello, I want to build a DOM document using SAX2 events that are generated by a custom module. I didn't find any easy way to plug such an event generator within xerces. Am I missing something ? Thanks Fabrice -- Fabrice Desré - France Telecom R&D/DMI/GRI Tel: 5199923229 Fax: 5199923229 --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 16:05:29 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 48890 invoked by uid 500); 1 Oct 2001 16:05:28 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Delivered-To: moderator for garciaoscar@example.com Received: (qmail 53673 invoked from network); 1 Oct 2001 08:34:36 -0000 Message-ID: <garciaoscar@example.com> From: garciaoscar@example.com To: garciaoscar@example.com Subject: Xerces and Tuxedo Transaction Manager Date: Mon, 1 Oct 2001 10:16:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Is anyone using Xerces and Tuxedo Transaction Manager? We have tried to = use Xerces 1.5 and Tuxedo 6.5 running HP-UX 11.0, but have some problems = with coredumps (Bus errors and Segmentation Violation) at random places = within Xerces. Are there any known problems using this combination, or any workarounds that we aren't aware of. Regards Jens Christensen > Scandinavian IT Group > CPHVV-D Sales & Revenue Management Solutions Email: garciaoscar@example.com > Engvej 155 > 2300 K=F8benhavn S. > Copenhagen DK > Tel. 5199923229 > www.scandinavianIT.com >=20 >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 16:05:29 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 48941 invoked by uid 500); 1 Oct 2001 16:05:29 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Delivered-To: moderator for garciaoscar@example.com Received: (qmail 75998 invoked from network); 1 Oct 2001 11:02:10 -0000 X-Authentication-Warning: stoodg.utc.telenet.ru: max owned process doing -bs Date: Mon, 1 Oct 2001 17:02:03 +0600 (YEKST) From: Max Gotlib <garciaoscar@example.com> X-X-Sender: <garciaoscar@example.com> To: Michael Huedepohl <garciaoscar@example.com> cc: <garciaoscar@example.com> Subject: XercesC under FreeBSD... Message-ID: <garciaoscar@example.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1592387416-1001934123=:41353" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --0-1592387416-1001934123=:41353 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! I've searched through the XercesC-related mailing lists, looking for hints on compiling XercesC under FreeBSD (I'm running 4.2 and 4.4). The solution (patch) you've posted to the *-dev list makes it possible to compile it with ICU transcoding staff. I was able to build the package for Iconv transcoding subsystem (the patch against yours one is attached). The main problem is caused by the lack of wsc* functions in the FreeBSD libc and "unexpected" behavior of wcstombs() and mbstowsc() functions, called with NULL arguments... I was speaking about XercesC-1.5.1... Max. --0-1592387416-1001934123=:41353 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="xerces-c-src1_5_1.freebsd.transcoding.diff" Content-Transfer-Encoding: BASE64 Content-ID: <garciaoscar@example.com> Content-Description: Content-Disposition: attachment; filename="xerces-c-src1_5_1.freebsd.transcoding.diff" ZGlmZiAtcnVOIHhlcmNlcy1jLXNyYzFfNV8xL3NyYy91dGlsL1RyYW5zY29k ZXJzL0ljb252L0ljb252VHJhbnNTZXJ2aWNlLmNwcCB4ZXJjZXMvc3JjL3V0 aWwvVHJhbnNjb2RlcnMvSWNvbnYvSWNvbnZUcmFuc1NlcnZpY2UuY3BwDQot LS0geGVyY2VzLWMtc3JjMV81XzEvc3JjL3V0aWwvVHJhbnNjb2RlcnMvSWNv bnYvSWNvbnZUcmFuc1NlcnZpY2UuY3BwCVdlZCBKdWwgMTggMjA6MTU6NTYg MjAwMQ0KKysrIHhlcmNlcy9zcmMvdXRpbC9UcmFuc2NvZGVycy9JY29udi9J Y29udlRyYW5zU2VydmljZS5jcHAJU3VuIFNlcCAzMCAyMTozMTo0MSAyMDAx DQpAQCAtNjksNiArNjksOSBAQA0KICNpZiBkZWZpbmVkIChYTUxfR0NDKSB8 fCBkZWZpbmVkIChYTUxfUFRYKSB8fCBkZWZpbmVkIChYTUxfSUJNVkFPUzIp DQogI2luY2x1ZGUgPHdjdHlwZS5oPg0KICNlbmRpZg0KKyNpZmRlZiBYTUxf RlJFRUJTRA0KKyNpbmNsdWRlIDxjdHlwZS5oPg0KKyNlbmRpZg0KICNpbmNs dWRlIDxzdHJpbmcuaD4NCiAjaW5jbHVkZSA8c3RkbGliLmg+DQogI2luY2x1 ZGUgPHN0ZGlvLmg+DQpAQCAtOTksNyArMTAyLDgyIEBADQogICAgIHJldHVy biBsZW47DQogfQ0KIA0KKyNpZmRlZiBYTUxfRlJFRUJTRA0KIA0KKy8vIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KKy8vIEZyZWVCU0QgZ290 IHRoZSB3aWRlLWNoYXJhY3RlcnMgc3VwcG9ydCBzaW5jZSA0LjAgdmVyc2lv bi4gQnV0IChhdCBsZWFzdA0KKy8vIHVwIHRvIHRoZSA0LjQpIHRoaXMgc3Vw cG9ydCBkaWZmZXJzIGZyb20gIm90aGVycyIgaW4gdGhhdCB0aGUgeHhzdG95 eXMoKQ0KKy8vIGRvZXMgbm90IGhhbmRsZSB0aGUgTlVMTC1kZXN0IGFyZ3Vt ZW50IHByb3Blcmx5LiBTbyB0aGUgY3VzdG9tIGZ1bmN0aW9ucw0KKy8vIGFy ZSBwcm92aWRlZC4NCisvLyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCisNCisjZGVmaW5lIF9fVE1QX0FSUkFZX1NJWkVfXyAgICAgIDQNCisN CitzdGF0aWMgc2l6ZV90DQorZmJzZF93Y3N0b21icyggY2hhciAqZGVzdCwg Y29uc3Qgd2NoYXJfdCAqc3JjLCBzaXplX3QgbiApDQorew0KKyAgICBjaGFy ICAgICAgICB0YXJyWyBfX1RNUF9BUlJBWV9TSVpFX18gKyAxIF07DQorICAg IHNpemVfdCAgICAgIGxlbiA9IDAsIGxlbnQgPSAwOw0KKyAgICBjaGFyKiAg ICAgICBwdHI7DQorICAgIHNpemVfdCAgICAgIHNsZW47DQorICAgIHdjaGFy X3QqICAgIHdwdHI7DQorICAgIA0KKyAgICBpZiggZGVzdCApDQorICAgICAg ICByZXR1cm4oIDo6d2NzdG9tYnMoZGVzdCwgc3JjLCBuKSApOw0KKyAgICBp ZiggIXNyYyApDQorICAgICAgICByZXR1cm4oIDAgKTsNCisgICAgZm9yKCB3 cHRyID0gKHdjaGFyX3QgKikgc3JjLCBzbGVuID0gMDsgKndwdHI7IHdwdHIr Kywgc2xlbisrICk7DQorICAgIGlmKCBzbGVuID09IDAgKQ0KKyAgICAgICAg cmV0dXJuKCAwICk7DQorICAgIHdwdHIgPSAod2NoYXJfdCAqKSBzcmM7DQor ICAgIHB0ciA9IGRlc3Q7DQorICAgIHdoaWxlKCAobGVuID0gOjp3Y3N0b21i cyh0YXJyLCB3cHRyLCBfX1RNUF9BUlJBWV9TSVpFX18pKSA+IDAgKSB7DQor ICAgICAgICB3cHRyICs9IGxlbjsNCisgICAgICAgIGxlbnQgKz0gbGVuOw0K KyAgICB9DQorICAgIGlmKCBsZW4gPT0gKHVuc2lnbmVkKSAtMSApDQorICAg ICAgICByZXR1cm4oIDAgKTsNCisgICAgcmV0dXJuKCBsZW50ICk7DQorfQ0K Kw0KK3N0YXRpYyBzaXplX3QNCitmYnNkX21ic3Rvd2NzKCB3Y2hhcl90ICpk ZXN0LCBjb25zdCBjaGFyICpzcmMsIHNpemVfdCBuICkNCit7DQorICAgIHdj aGFyX3QgICAgIHRhcnJbIF9fVE1QX0FSUkFZX1NJWkVfXyArIDEgXTsNCisg ICAgc2l6ZV90ICAgICAgbGVuID0gMCwgbGVudCA9IDA7DQorICAgIGNoYXIq ICAgICAgIHB0cjsNCisNCisgICAgaWYoIGRlc3QgKQ0KKyAgICAgICAgcmV0 dXJuKCA6Om1ic3Rvd2NzKGRlc3QsIHNyYywgbiApICk7DQorICAgIHB0ciA9 IChjaGFyKikgc3JjOw0KKyAgICBpZiggIXNyYyB8fCBzdHJsZW4oc3JjKSA9 PSAwICkNCisgICAgICAgIHJldHVybiggMCApOw0KKyAgICB3aGlsZSggKGxl biA9IDo6bWJzdG93Y3ModGFyciwgcHRyLCBfX1RNUF9BUlJBWV9TSVpFX18p KSA+IDAgKSB7DQorICAgICAgICBwdHIgKz0gbGVuOw0KKyAgICAgICAgbGVu dCArPSBsZW47DQorICAgIH0NCisgICAgaWYoIGxlbiA9PSAodW5zaWduZWQp IC0xICkNCisgICAgICAgIHJldHVybiggMCApOw0KKyAgICByZXR1cm4oIGxl bnQgKTsNCit9DQorDQorI2RlZmluZSB4X21ic3Rvd2NzICAgICAgZmJzZF9t YnN0b3djcw0KKyNkZWZpbmUgeF93Y3N0b21icyAgICAgIGZic2Rfd2NzdG9t YnMNCisNCisNCitzdGF0aWMgWE1MQ2ggdG93dXBwZXIoIFhNTENoIGNoICkN Cit7DQorICAgIGNoYXIgYnVmWzE2XTsNCisgICAgd2NzdG9tYnMoIGJ1Ziwg KHdjaGFyX3QqKSAmY2gsIDEgKTsNCisgICAgcmV0dXJuIHRvdXBwZXIoY2gp Ow0KK30NCisNCisjZWxzZQ0KKw0KKyNkZWZpbmUgeF9tYnN0b3djcyAgICAg IG1ic3Rvd2NzDQorI2RlZmluZSB4X3djc3RvbWJzICAgICAgd2NzdG9tYnMN CisNCisjZW5kaWYgLyogWE1MX0ZSRUVCU0QgKi8NCiANCiAvLyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAvLyAgSWNvbnZUcmFuc1NlcnZp Y2U6IENvbnN0cnVjdG9ycyBhbmQgRGVzdHJ1Y3Rvcg0KQEAgLTE3OSw3ICsy NTcsMTMgQEANCiANCiBib29sIEljb252VHJhbnNTZXJ2aWNlOjppc1NwYWNl KGNvbnN0IFhNTENoIHRvQ2hlY2spIGNvbnN0DQogew0KKyNpZmRlZiBYTUxf RlJFRUJTRA0KKyAgICBjaGFyIGJ1ZlsxNl07DQorICAgIG1ic3Rvd2NzKCAo d2NoYXJfdCopICZ0b0NoZWNrLCBidWYsIDEgKTsNCisgICAgcmV0dXJuIChp c3NwYWNlKCpidWYpICE9IDApOw0KKyNlbHNlDQogICAgIHJldHVybiAoaXN3 c3BhY2UodG9DaGVjaykgIT0gMCk7DQorI2VuZGlmDQogfQ0KIA0KIA0KQEAg LTIzNSw3ICszMTksNyBAQA0KICAgICBpZiAoIXNyY1RleHQpDQogICAgICAg ICByZXR1cm4gMDsNCiANCi0gICAgY29uc3QgdW5zaWduZWQgaW50IHJldFZh bCA9IDo6bWJzdG93Y3MoTlVMTCwgc3JjVGV4dCwgMCk7DQorICAgIGNvbnN0 IHVuc2lnbmVkIGludCByZXRWYWwgPSB4X21ic3Rvd2NzKE5VTEwsIHNyY1Rl eHQsIDApOw0KIA0KICAgICBpZiAocmV0VmFsID09IH4wKQ0KICAgICAgICAg cmV0dXJuIDA7DQpAQCAtMjY0LDcgKzM0OCw3IEBADQogICAgIH0NCiAgICAg d2lkZUNoYXJCdWZbd0xlbnRdID0gMHgwMDsNCiANCi0gICAgY29uc3QgdW5z aWduZWQgaW50IHJldFZhbCA9IDo6d2NzdG9tYnMoTlVMTCwgd2lkZUNoYXJC dWYsIDApOw0KKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgcmV0VmFsID0geF93 Y3N0b21icyhOVUxMLCB3aWRlQ2hhckJ1ZiwgMCk7DQogICAgIGRlbGV0ZSBb XSBhbGxvY2F0ZWRBcnJheTsNCiANCiAgICAgaWYgKHJldFZhbCA9PSB+MCkN CkBAIC0yOTksNyArMzgzLDcgQEANCiAgICAgICAgIHdpZGVDaGFyQnVmW3dM ZW50XSA9IDB4MDA7DQogDQogICAgICAgICAvLyBDYWxjIHRoZSBuZWVkZWQg c2l6ZS4NCi0gICAgICAgIGNvbnN0IHNpemVfdCBuZWVkZWRMZW4gPSA6Ondj c3RvbWJzKE5VTEwsIHdpZGVDaGFyQnVmLCAwKTsNCisgICAgICAgIGNvbnN0 IHNpemVfdCBuZWVkZWRMZW4gPSB4X3djc3RvbWJzKE5VTEwsIHdpZGVDaGFy QnVmLCAwKTsNCiAgICAgICAgIGlmIChuZWVkZWRMZW4gPT0gLTEpDQogICAg ICAgICB7DQogICAgICAgICAgICAgZGVsZXRlIFtdIGFsbG9jYXRlZEFycmF5 Ow0KQEAgLTMwNyw3ICszOTEsNyBAQA0KICAgICAgICAgfQ0KIA0KICAgICAg ICAgcmV0VmFsID0gbmV3IGNoYXJbbmVlZGVkTGVuICsgMV07DQotICAgICAg ICA6Ondjc3RvbWJzKHJldFZhbCwgd2lkZUNoYXJCdWYsIG5lZWRlZExlbik7 DQorICAgICAgICB4X3djc3RvbWJzKHJldFZhbCwgd2lkZUNoYXJCdWYsIG5l ZWRlZExlbik7DQogICAgICAgICByZXRWYWxbbmVlZGVkTGVuXSA9IDA7DQog ICAgICAgICBkZWxldGUgW10gYWxsb2NhdGVkQXJyYXk7DQogICAgIH0NCkBA IC0zNTgsNyArNDQyLDcgQEANCiAgICAgd2lkZUNoYXJCdWZbd0xlbnRdID0g MHgwMDsNCiANCiAgICAgLy8gT2ssIGdvIGFoZWFkIGFuZCB0cnkgdGhlIHRy YW5zY29kaW5nLiBJZiBpdCBmYWlscywgdGhlbiAuLi4NCi0gICAgaWYgKDo6 d2NzdG9tYnModG9GaWxsLCB3aWRlQ2hhckJ1ZiwgbWF4Qnl0ZXMpID09IC0x KQ0KKyAgICBpZiAoeF93Y3N0b21icyh0b0ZpbGwsIHdpZGVDaGFyQnVmLCBt YXhCeXRlcykgPT0gLTEpDQogICAgIHsNCiAgICAgICAgIGRlbGV0ZSBbXSBh bGxvY2F0ZWRBcnJheTsNCiAgICAgICAgIHJldHVybiBmYWxzZTsNCkBAIC0z OTQsNyArNDc4LDcgQEANCiAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICB3 aWRlQ2hhckJ1ZiA9IHRtcFdpZGVDaGFyQXJyOw0KIA0KLSAgICAgICAgOjpt YnN0b3djcyh3aWRlQ2hhckJ1ZiwgdG9UcmFuc2NvZGUsIGxlbik7DQorICAg ICAgICB4X21ic3Rvd2NzKHdpZGVDaGFyQnVmLCB0b1RyYW5zY29kZSwgbGVu KTsNCiAgICAgICAgIHJldFZhbCA9IG5ldyBYTUxDaFtsZW4gKyAxXTsNCiAg ICAgICAgIGZvciAodW5zaWduZWQgaW50IGkgPSAwOyBpIDwgbGVuOyBpKysp DQogICAgICAgICB7DQpAQCAtNDQzLDcgKzUyNyw3IEBADQogICAgIGVsc2UN CiAgICAgICAgIHdpZGVDaGFyQnVmID0gdG1wV2lkZUNoYXJBcnI7DQogDQot ICAgIGlmICg6Om1ic3Rvd2NzKHdpZGVDaGFyQnVmLCB0b1RyYW5zY29kZSwg bWF4Q2hhcnMpID09IC0xKQ0KKyAgICBpZiAoeF9tYnN0b3djcyh3aWRlQ2hh ckJ1ZiwgdG9UcmFuc2NvZGUsIG1heENoYXJzKSA9PSAtMSkNCiAgICAgew0K ICAgICAgICAgZGVsZXRlIFtdIGFsbG9jYXRlZEFycmF5Ow0KICAgICAgICAg cmV0dXJuIGZhbHNlOw0K --0-1592387416-1001934123=:41353 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com --0-1592387416-1001934123=:41353-- From xerces-garciaoscar@example.com Mon Oct 01 16:42:44 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 98796 invoked by uid 500); 1 Oct 2001 16:42:44 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 98779 invoked from network); 1 Oct 2001 16:42:43 -0000 Message-ID: <garciaoscar@example.com> From: "Christy, Rich" <garciaoscar@example.com> To: "'garciaoscar@example.com'" <garciaoscar@example.com> Subject: Possible memory leak in IDOM_Element888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getElementsByTagName()???? Date: Mon, 1 Oct 2001 11:42:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I trying to determine if this is a problem or not. But each time I call getElementsByTagName(), it works its way down to IDDeepNodeListImpl888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getDeepNodeList() where memory is allocated to and inserted into the node list pool. Purify claims a memory leak is occurring. I cannot find any where in the logic where IDDeepNodeListPool888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4removeAll() is called. Am I just missing something or is this a bug. I've added a call to XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Terminate(), but that doesn't seem to make a difference. thanks Rich Christy garciaoscar@example.com --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 17:10:01 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 38023 invoked by uid 500); 1 Oct 2001 17:10:01 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 38010 invoked from network); 1 Oct 2001 17:10:00 -0000 Sender: michael Message-ID: <garciaoscar@example.com> Date: Mon, 01 Oct 2001 19:09:26 +0200 From: Michael Huedepohl <garciaoscar@example.com> X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: Max Gotlib <garciaoscar@example.com> CC: garciaoscar@example.com Subject: Re: XercesC under FreeBSD... References: <garciaoscar@example.com> Content-Type: multipart/mixed; boundary="------------3672EABE1D0954A4F2EEB3F3" X-OriginalArrivalTime: 01 Oct 2001 17:09:32.0912 (UTC) FILETIME=[D6E9D700:01C14A9B] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --------------3672EABE1D0954A4F2EEB3F3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Max Gotlib wrote: > > I've searched through the XercesC-related mailing lists, looking for hints > on compiling XercesC under FreeBSD (I'm running 4.2 and 4.4). The solution > (patch) you've posted to the *-dev list makes it possible to compile it > with ICU transcoding staff. I was able to build the package for Iconv > transcoding subsystem (the patch against yours one is attached). The main > problem is caused by the lack of wsc* functions in the FreeBSD libc and > "unexpected" behavior of wcstombs() and mbstowsc() functions, called with > NULL arguments... I was speaking about XercesC-1.5.1... I've tried your patch and first of all - after successfully patching the source and configuring with runConfigure -p freebsd -nsocket -tnative -rpthread (I suppose that's what you intended - right?) I got the following error message from the gcc compiler: IconvTransService.cpp:68: wchar.h: No such file or directory IconvTransService.cpp:70: wctype.h: No such file or directory I found that you still include these files which don't exist on FreeBSD 4.3 (and most probably also don't exist on 4.2 or 4.4). I modified the ifdef's so that these include files are not requested if XML_FREEBSD is defined. Then I got the following error: IconvTransService.cpp: In method `int IconvTransServi888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4compareIString(const XMLCh *, const XMLCh *)': IconvTransService.cpp:207: syntax error before `=' Obviously, wint_t is unknown to the compiler, and since the towupper function provided by you returns XMLCh, I added a definition #define wint_t XMLCh into the XML_FREEBSD branch from above. With these modifications, I could create the library, and it seems to work with our applications as well as the version with ICU transcoder. I'm attaching the modified patch for Iconv. If you agree to my changes, I can create a new patch for both, i.e. my ICU patch from last week with your Iconv patch integrated. Michael --------------3672EABE1D0954A4F2EEB3F3 Content-Type: text/plain; charset=us-ascii; name="xerces1.5.1src-bsd-iconv-fixed.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xerces1.5.1src-bsd-iconv-fixed.diff" --- util/Transcoders/Iconv/IconvTransService.cpp.orig Wed Jul 18 16:15:56 2001 +++ util/Transcoders/Iconv/IconvTransService.cpp Mon Oct 1 16:55:06 2001 @@ -65,10 +65,15 @@ #include <util/XMLUniDefs.hpp> #include <util/XMLUni.hpp> #include "IconvTransService.hpp" +#ifdef XML_FREEBSD +#include <ctype.h> +#define wint_t XMLCh +#else #include <wchar.h> #if defined (XML_GCC) || defined (XML_PTX) || defined (XML_IBMVAOS2) #include <wctype.h> #endif +#endif #include <string.h> #include <stdlib.h> #include <stdio.h> @@ -99,8 +104,83 @@ return len; } +#ifdef XML_FREEBSD + +// --------------------------------------------------------------------------- +// FreeBSD got the wide-characters support since 4.0 version. But (at least +// up to the 4.4) this support differs from "others" in that the xxstoyys() +// does not handle the NULL-dest argument properly. So the custom functions +// are provided. +// --------------------------------------------------------------------------- + +#define __TMP_ARRAY_SIZE__ 4 + +static size_t +fbsd_wcstombs( char *dest, const wchar_t *src, size_t n ) +{ + char tarr[ __TMP_ARRAY_SIZE__ + 1 ]; + size_t len = 0, lent = 0; + char* ptr; + size_t slen; + wchar_t* wptr; + + if( dest ) + return( 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4wcstombs(dest, src, n) ); + if( !src ) + return( 0 ); + for( wptr = (wchar_t *) src, slen = 0; *wptr; wptr++, slen++ ); + if( slen == 0 ) + return( 0 ); + wptr = (wchar_t *) src; + ptr = dest; + while( (len = 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4wcstombs(tarr, wptr, __TMP_ARRAY_SIZE__)) > 0 ) { + wptr += len; + lent += len; + } + if( len == (unsigned) -1 ) + return( 0 ); + return( lent ); +} + +static size_t +fbsd_mbstowcs( wchar_t *dest, const char *src, size_t n ) +{ + wchar_t tarr[ __TMP_ARRAY_SIZE__ + 1 ]; + size_t len = 0, lent = 0; + char* ptr; + + if( dest ) + return( 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4mbstowcs(dest, src, n ) ); + ptr = (char*) src; + if( !src || strlen(src) == 0 ) + return( 0 ); + while( (len = 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4mbstowcs(tarr, ptr, __TMP_ARRAY_SIZE__)) > 0 ) { + ptr += len; + lent += len; + } + if( len == (unsigned) -1 ) + return( 0 ); + return( lent ); +} + +#define x_mbstowcs fbsd_mbstowcs +#define x_wcstombs fbsd_wcstombs +static XMLCh towupper( XMLCh ch ) +{ + char buf[16]; + wcstombs( buf, (wchar_t*) &ch, 1 ); + return toupper(ch); +} + +#else + +#define x_mbstowcs mbstowcs +#define x_wcstombs wcstombs + +#endif /* XML_FREEBSD */ + // --------------------------------------------------------------------------- // IconvTransService: Constructors and Destructor // --------------------------------------------------------------------------- @@ -179,7 +259,13 @@ bool IconvTransServi888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4isSpace(const XMLCh toCheck) const { +#ifdef XML_FREEBSD + char buf[16]; + mbstowcs( (wchar_t*) &toCheck, buf, 1 ); + return (isspace(*buf) != 0); +#else return (iswspace(toCheck) != 0); +#endif } @@ -235,7 +321,7 @@ if (!srcText) return 0; - const unsigned int retVal = 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4mbstowcs(NULL, srcText, 0); + const unsigned int retVal = x_mbstowcs(NULL, srcText, 0); if (retVal == ~0) return 0; @@ -264,7 +350,7 @@ } wideCharBuf[wLent] = 0x00; - const unsigned int retVal = 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4wcstombs(NULL, wideCharBuf, 0); + const unsigned int retVal = x_wcstombs(NULL, wideCharBuf, 0); delete [] allocatedArray; if (retVal == ~0) @@ -299,7 +385,7 @@ wideCharBuf[wLent] = 0x00; // Calc the needed size. - const size_t neededLen = 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4wcstombs(NULL, wideCharBuf, 0); + const size_t neededLen = x_wcstombs(NULL, wideCharBuf, 0); if (neededLen == -1) { delete [] allocatedArray; @@ -307,7 +393,7 @@ } retVal = new char[neededLen + 1]; - 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4wcstombs(retVal, wideCharBuf, neededLen); + x_wcstombs(retVal, wideCharBuf, neededLen); retVal[neededLen] = 0; delete [] allocatedArray; } @@ -358,7 +444,7 @@ wideCharBuf[wLent] = 0x00; // Ok, go ahead and try the transcoding. If it fails, then ... - if (888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4wcstombs(toFill, wideCharBuf, maxBytes) == -1) + if (x_wcstombs(toFill, wideCharBuf, maxBytes) == -1) { delete [] allocatedArray; return false; @@ -394,7 +480,7 @@ else wideCharBuf = tmpWideCharArr; - 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4mbstowcs(wideCharBuf, toTranscode, len); + x_mbstowcs(wideCharBuf, toTranscode, len); retVal = new XMLCh[len + 1]; for (unsigned int i = 0; i < len; i++) { @@ -443,7 +529,7 @@ else wideCharBuf = tmpWideCharArr; - if (888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4mbstowcs(wideCharBuf, toTranscode, maxChars) == -1) + if (x_mbstowcs(wideCharBuf, toTranscode, maxChars) == -1) { delete [] allocatedArray; return false; --------------3672EABE1D0954A4F2EEB3F3 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com --------------3672EABE1D0954A4F2EEB3F3-- From xerces-garciaoscar@example.com Mon Oct 01 19:44:50 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 17740 invoked by uid 500); 1 Oct 2001 19:44:50 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 17715 invoked from network); 1 Oct 2001 19:44:49 -0000 Message-ID: <garciaoscar@example.com> From: Nick Denning <garciaoscar@example.com> To: "'garciaoscar@example.com'" <garciaoscar@example.com> Subject: RE: Xerces and Tuxedo Transaction Manager Date: Mon, 1 Oct 2001 20:45:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I am using TUXEDO 6.4 and XERCES for our MQ to TUXEDO gateway product = which has run on Solaris, AIX and NT though admittedly not in production on = HP UX. The only problem I have had with TUXEDO was naming a library libgw = which is the same as one of the TUXEDO libraries. All other aspects have been = fine, and I would be very surprised if you have a fundamental issue. However do you really mean 1.5 as that has terrible memory leakage = problems, so if you really do mean 1.5 then I suggest going to 1.5.1. We have another customer who is asking us to go to TUXEDO 7.1 and soon = to TUXEDO 8 so I will be proving with other versions in due course. Nick -----Original Message----- From: garciaoscar@example.com [mailto:garciaoscar@example.com] Sent: 01 October 2001 09:16 To: garciaoscar@example.com Subject: Xerces and Tuxedo Transaction Manager Is anyone using Xerces and Tuxedo Transaction Manager? We have tried to = use Xerces 1.5 and Tuxedo 6.5 running HP-UX 11.0, but have some problems = with coredumps (Bus errors and Segmentation Violation) at random places = within Xerces. Are there any known problems using this combination, or any workarounds that we aren't aware of. Regards Jens Christensen > Scandinavian IT Group > CPHVV-D Sales & Revenue Management Solutions Email: garciaoscar@example.com > Engvej 155 > 2300 K=F8benhavn S. > Copenhagen DK > Tel. 5199923229 > www.scandinavianIT.com >=20 >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com ************************************************************************= *=20 This message contains privileged and confidential information intended=20 only for the use of the recipient named above. Its contents do not=20 constitute a commitment by Strategic Thought Limited ("Strategic=20 Thought") unless separately endorsed by an authorised representative=20 of Strategic Thought.=20 =20 Any use, dissemination, distribution, reproduction or unauthorised=20 disclosure of this message is prohibited. If you receive this message=20 in error, please notify the sender immediately and delete it from your=20 computer systems.=20 =20 Any views expressed in this message are those of the individual sender=20 and may not necessarily reflect those of Strategic Thought.=20 =20 Strategic Thought believes this e-mail and any attachments to be virus=20 free. However, the recipient is responsible for ensuring it is virus=20 free and Strategic Thought do not accept any responsibility for any=20 loss or damage howsoever caused from use of this e-mail, attachments=20 or contents.=20 ************************************************************************= *=20 --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 19:58:13 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 42584 invoked by uid 500); 1 Oct 2001 19:58:12 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 42555 invoked from network); 1 Oct 2001 19:58:12 -0000 X-Originating-IP: [83.161.120.155] From: "Jeffrey Rodriguez" <garciaoscar@example.com> To: garciaoscar@example.com Bcc: Subject: Fwd: Re: Pull parsing mode-- Is it implemented Date: Mon, 01 Oct 2001 19:57:51 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <garciaoscar@example.com> X-OriginalArrivalTime: 01 Oct 2001 19:57:51.0914 (UTC) FILETIME=[5A6340A0:01C14AB3] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Does Xerces-C implement pull parsing event mode? Thanks, Jeffrey Rodriguez >> >>Jeffrey Rodriguez wrote: >> > I remember last year talks about providing a way to use the parser >> > in a a Pull parsing event mode ( versus the pushing mode of the SAX >>parser >> > today). >> >>Which version of Xerces are you referring to? Both Xerces 1.x >>and Xerces2 have implemented pull-parse capability but they >>do it differently. >> >>In Xerces 1.x, there are methods on both parses that need to >>be called to do pull parsing. First, you call parseSomeSetup >>and then make repeated calls to parseSome to do the pull- >>parsing. I don't quite recall how many methods are called per >>call to the parseSome method but I think it's undetermined. >>Also, the delivery of character events is short circuited in >>the code. Therefore, the pull-parsing will not return until >>all of the character content between markup is delivered. >> >>Xerces2 also has pull-parsing capability but the methods are >>not immediately available through the parser. The reason for >>this is that the parser classes that build DOM trees or emit >>SAX events need to work generically with all kinds of parser >>configurations which may or may not support pull-parsing. So >>we have introduced an interface that descends from the parser >>configuration interface and adds methods for pull-parsing. >> >>Since the standard Xerces2 scanner component can operate in >>a step-by-step fashion, the StandardParserConfiguration >>implements the XMLPullParserConfiguration interface. So you >>can do pull-parsing (of a DOM tree) with the following code: >> >> XMLPullParserConfiguration config = >> new StandardParserConfiguration(); >> DOMParser parser = new DOMParser(config); >> >> config.setInputSource(/* XMLInputSource */); >> while (config.parse(false)) { >> // do something >> } >> >>However, don't assume that each call to parse(false) has >>a one-to-one relationship with how many XNI handler >>methods are called. It may be zero or it may be many. >>But the scanner *will* stop and return control to the >>application at "reasonable" points. There are two reasons >>why it's not one-to-one: 1) the implementation isn't >>broken down enough to make sure that one and only one >>XNI handler method is called per step; and 2) even if >>we implemented the correct breakdown in the scanner, >>later stages in the pipeline can generate additional >>events (e.g. the namespace binder). >> >>Hope this helps. >> >>-- >>Andy Clark * IBM, TRL - Japan * garciaoscar@example.com >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: garciaoscar@example.com >>For additional commands, e-mail: garciaoscar@example.com >> > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: garciaoscar@example.com >For additional commands, e-mail: garciaoscar@example.com > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 20:17:40 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 69629 invoked by uid 500); 1 Oct 2001 20:17:39 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 69618 invoked from network); 1 Oct 2001 20:17:39 -0000 Date: 1 Oct 2001 20:17:43 -0000 Message-ID: <garciaoscar@example.com> From: garciaoscar@example.com To: garciaoscar@example.com Cc: Subject: DO NOT REPLY [Bug 3909] New: - Parser Library Code Exits on Fatal Error with exit code 0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3909>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3909 Parser Library Code Exits on Fatal Error with exit code 0 Summary: Parser Library Code Exits on Fatal Error with exit code 0 Product: Xerces-C++ Version: 1.5.1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: DOM AssignedTo: garciaoscar@example.com ReportedBy: garciaoscar@example.com When parsing some XML using the domcount sample program, I noticed that after the error handling code printed a message that a Fatal Error had occurred the program would exit. Since I was calling this executable from within another program I was checking for the exit code and none was detected. Following through the debugger revealed that the program was exiting somewhere within the parse object and not attempting to return control to the calling program. While the problem with the sample code itself is not critical, not returning control to the calling program is. --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 21:34:59 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 75675 invoked by uid 500); 1 Oct 2001 21:34:58 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 75459 invoked from network); 1 Oct 2001 21:34:57 -0000 Message-ID: <garciaoscar@example.com> From: "Houle, Dennis W" <garciaoscar@example.com> To: "'garciaoscar@example.com'" <garciaoscar@example.com> Subject: RE: Possible memory leak in IDOM_Element888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getElementsByTagName()? ??? Date: Mon, 1 Oct 2001 14:39:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Rich, I can respond to your IDOM memory questions as an IDOM user, not a developer of the IDOM API. My understanding is that the IDOM_Document manages the memory needs of its nodes/elements. That is why you never delete pointers returned from IDOM operations (e.g. getAttribute, item, getFirstChild, etc.) All of the memory used by an IDOM_Document and its nodes/elements is released when you are finished with the IDOM_Document and delete its pointer. Also, be sure you are using a recent release, the folowing IDDeepNodeListImpl bug was fixed in early August: * Revision 1.5 2001/08/07 17:01:09 tng * [Bug 2676] IDOM: pure virtual called in IDDeepNodeListImpl888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4item() . Any clarifications or corrections from an IDOM developer would be most welcome! - Dennis -----Original Message----- From: Christy, Rich [mailto:garciaoscar@example.com] Sent: Monday, October 01, 2001 9:43 AM To: 'garciaoscar@example.com' Subject: Possible memory leak in IDOM_Element888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getElementsByTagName()???? I trying to determine if this is a problem or not. But each time I call getElementsByTagName(), it works its way down to IDDeepNodeListImpl888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getDeepNodeList() where memory is allocated to and inserted into the node list pool. Purify claims a memory leak is occurring. I cannot find any where in the logic where IDDeepNodeListPool888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4removeAll() is called. Am I just missing something or is this a bug. I've added a call to XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Terminate(), but that doesn't seem to make a difference. thanks Rich Christy garciaoscar@example.com --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 22:36:36 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 58842 invoked by uid 500); 1 Oct 2001 22:36:32 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 58817 invoked from network); 1 Oct 2001 22:36:31 -0000 To: garciaoscar@example.com Subject: Schema checking requires namespaces? From: garciaoscar@example.com (Jason E. Stewart) Date: 01 Oct 2001 16:36:05 -0600 Message-ID: <garciaoscar@example.com> Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hey All, I was writing an EntityResolver example for use with XML Schemas to see how it would work, and I discovered that in order to get xerces to check your schema you must also enable namespaces. Is there any reason I would want to set setDoSchema() to true but *not* want namespaces enabled? If there isn't why shouldn't setDoSchema() also set namespaces? jas. --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 23:03:47 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 86061 invoked by uid 500); 1 Oct 2001 23:03:47 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 86028 invoked from network); 1 Oct 2001 23:03:46 -0000 To: "Vladimir Sinichkin" <garciaoscar@example.com> Cc: garciaoscar@example.com Subject: Re: schema is in string, not in file References: <001401c1476e$610cfba0$cd6b96d4@vladimir> <garciaoscar@example.com> <001201c1477a$92c54ab0$497996d4@vladimir> <garciaoscar@example.com> <001001c148d5$9eaf3140$b96b96d4@vladimir> From: garciaoscar@example.com (Jason E. Stewart) Date: 01 Oct 2001 17:03:15 -0600 In-Reply-To: <001001c148d5$9eaf3140$b96b96d4@vladimir> Message-ID: <garciaoscar@example.com> Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N "Vladimir Sinichkin" <garciaoscar@example.com> writes: > Thanx a lot for your recommendations :-) You helped me very much! Great, glad to hear it. I've learned a bit myself ;-) > But I still have 2 more small questions: > > 1. Do I have to keep xsi:noNamespaceSchemaLocation='' attribute in my xml > string? > Is there any other way to tell to the parser to use a schema, which I > provide by EntityResolver? Apparently not. You just need to supply enough information about the name of the schema (which gets passed as the systemId argument to resolveEntity()) so that you get get what you need from your DB. > 2. As you told me I wrote subclass from EntityResolver. This class has a > method > resolveEntity that gets 2 arguments: > InputSource* SchemaResolver888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4resolveEntity(const XMLCh* const publicId, > const XMLCh* const systemId) ; > I need to use those arguments to bring right schema for different > versions of XMLs. > But the bpoblem is that this method is called by the parser (not by ne > script). > So, the question is how can I know what the parser passes in those 2 > arguments? > Is there any way to control it? Right. The parser will invoke resolveEntity() and it will pass the value of the *SchemaLocation attribute as the systemId argument. So your entity resolver needs to be able to take the system ID with that information create the appropriate schema from your DB, and return a MemBufInputSource to the parser. HTH, jas. --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Mon Oct 01 23:38:17 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 13982 invoked by uid 500); 1 Oct 2001 23:38:16 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 13971 invoked from network); 1 Oct 2001 23:38:16 -0000 Subject: Re: Schema checking requires namespaces? To: garciaoscar@example.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <garciaoscar@example.com> From: garciaoscar@example.com Date: Mon, 1 Oct 2001 19:36:00 -0400 X-MIMETrack: Serialize by Router on CAMMAIL08/CAM/M/Lotus(Release 5.0.8 |June 18, 2001) at 10/01/2001 07:36:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Theoretically, you _can_ write a Schema that defines only the default/unnamed namespace... but I sorta agree; if you're sophisticated enough to be using Schemas, you shouldn't be using pre-Namespace XML. --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Tue Oct 02 00:27:40 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 49977 invoked by uid 500); 2 Oct 2001 00:27:39 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 49966 invoked from network); 2 Oct 2001 00:27:39 -0000 Message-ID: <C84B9CD8CA54D311A18C0090274F3D8B738BC9@sm_srv1.nquire.com> From: Samar Abbas Lotia <garciaoscar@example.com> To: "'garciaoscar@example.com'" <garciaoscar@example.com> Subject: core dump on Solaris 8 when exceptions raised Date: Mon, 1 Oct 2001 17:27:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14AD9.0F05EDD0" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C14AD9.0F05EDD0 Content-Type: text/plain; charset="UTF-8" Hi all, I am using Sun Forte 6 Update 1 (C++ compiler version 5.2) and I see the following problem. When I compile with optimizations on, xerces crashes when an exception is raised. The easiest way I can reproduce the problem is to try and parse a file that doesn't exist, i.e. DOMParser tParser; tParser.parse("/doesnotexist.xml"); I saw some discussion in the list archives regarding this problem and the solution discovered was installation of patch 107390-10. However, this discussion was particular to the 5.0 version of the compiler. I was wondering if someone has seen similar problems with 5.2 and/or if there are patches applicable to this release of the compiler that address the problem. The code works fine when compiling with the '-g' flag and no optimizations. SAL ------_=_NextPart_001_01C14AD9.0F05EDD0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DUTF-8"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2653.12"> <TITLE>core dump on Solaris 8 when exceptions raised</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Hi all,</FONT> </P> <P><FONT SIZE=3D2>I am using Sun Forte 6 Update 1 (C++ compiler version = 5.2) and I see the following problem.</FONT> </P> <P><FONT SIZE=3D2>When I compile with optimizations on, xerces crashes = when an exception is raised. The easiest way I can reproduce the = problem is to try and parse a file that doesn't exist, i.e.</FONT></P> <P><FONT SIZE=3D2>DOMParser tParser;</FONT> <BR><FONT SIZE=3D2>tParser.parse(&quot;/doesnotexist.xml&quot;);</FONT> </P> <P><FONT SIZE=3D2>I saw some discussion in the list archives regarding = this problem and the solution discovered was installation of patch = 107390-10. However, this discussion was particular to the 5.0 version = of the compiler. I was wondering if someone has seen similar problems = with 5.2 and/or if there are patches applicable to this release of the = compiler that address the problem.</FONT></P> <P><FONT SIZE=3D2>The code works fine when compiling with the '-g' flag = and no optimizations.</FONT> </P> <P><FONT SIZE=3D2>SAL</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C14AD9.0F05EDD0-- From xerces-garciaoscar@example.com Tue Oct 02 16:16:08 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 74302 invoked by uid 500); 2 Oct 2001 16:16:07 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 74277 invoked from network); 2 Oct 2001 16:16:07 -0000 X-IMPORTANT-Address-Change: All doim6 addresses have changed to mail1. Example: garciaoscar@example.com is now garciaoscar@example.com Message-ID: <garciaoscar@example.com> From: "Altenau, Maureen D CECOM RDEC C2D" <garciaoscar@example.com> To: "'garciaoscar@example.com'" <garciaoscar@example.com> Subject: Binary files Date: Tue, 2 Oct 2001 12:16:04 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Jason, I think I have this down. Is the library that I need libxerces-c1_5_1.so? Also, I tried to configure the samples. The make file failed in the first subdirectory - SAXPrint when it accessed the ../Makefile.incl line 63. This is the code - ifeq (${SYSOVR}, OS400) PLATFORM = OS400 - this is line 63. endif I could not find where SYSOVR was defined. I then looked at the Makefile in SAXPrint. There were variables there that I could not find definitions for and some directories that did not exist like ${XERCESCROOT}/bin/obj. Am I correct in assuming that these variables need to be defined and some directories created? I did notice that there are executables in the bin directory. Are these the executables that the Makefiles create? Thanks for your help, Maureen --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Tue Oct 02 19:08:22 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 62598 invoked by uid 500); 2 Oct 2001 19:08:20 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 62577 invoked from network); 2 Oct 2001 19:08:20 -0000 Date: 2 Oct 2001 19:08:25 -0000 Message-ID: <garciaoscar@example.com> From: garciaoscar@example.com To: garciaoscar@example.com Cc: Subject: DO NOT REPLY [Bug 3867] - IDOM_Element888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getElementsByTagName() threading problem X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3867>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3867 IDOM_Element888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getElementsByTagName() threading problem garciaoscar@example.com changed: What |Removed |Added ---------------------------------------------------------------------------- garciaoscar@example.com |garciaoscar@example.com ------- Additional Comments From garciaoscar@example.com 2001-10-02 12:08 ------- Do you have a test case to reproduce the problem? I think I know what's wrong and working on a fix. If you can send me a test case to verify my fix, it is appreciated. Thanks! --------------------------------------------------------------------- To unsubscribe, e-mail: garciaoscar@example.com For additional commands, e-mail: garciaoscar@example.com From xerces-garciaoscar@example.com Wed Oct 03 02:22:54 2001 Return-Path: <xerces-garciaoscar@example.com> Delivered-To: garciaoscar@example.com Received: (qmail 61452 invoked by uid 500); 3 Oct 2001 02:22:53 -0000 Mailing-List: contact garciaoscar@example.com; run by ezmlm Precedence: bulk Reply-To: garciaoscar@example.com list-help: <mailto:garciaoscar@example.com> list-unsubscribe: <mailto:garciaoscar@example.com> list-post: <mailto:garciaoscar@example.com> Delivered-To: mailing list garciaoscar@example.com Received: (qmail 61415 invoked from network); 3 Oct 2001 02:22:53 -0000 User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 02 Oct 2001 19:22:33 -0700 Subject: Re: Windows 98 transcoder problem From: Geoff Coffey <garciaoscar@example.com> To: xerces c dev <garciaoscar@example.com> Message-ID: <garciaoscar@example.com> In-Reply-To: <garciaoscar@example.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N My understanding now is that the standard specification for wcstombs does not dictate that if a buffer size of zero is passed in, the size needed should be returned. This seems only to be a (documented) side effect of the implementation in VC++ and Borland. It also doesn't dictate that the wchar_t* be transcoded to the local code page (?). In the CodeWarrior implementation, as of version 7, wcstombs transcodes the wchar_t* to UTF8, which complies with the standard in their opinion (since UTF8 is a "multi-byte string"). So in my mind, the implementation in "Win32Transcoder.cpp" is a bug. It should instead call WideCharToMultiByte directly, which has the behavior desired across all compilers. Since this is a platform-specific source file, I see no reason to use the standard c routine when the Win32 routine is by default available. Does this make sense? Is this the kind of thing that should be reported as a bug? I've already fixed it on my end as it is a very simple change. Thanks, Geoff On 9/28/01 3:33 AM, "Don Mastrovito" <garciaoscar@example.com> wrote: > Goeff and Dean, > > After looking at the C RTL sources for both Borland and MSVC, wcstombs() > returns -1 on errors using either compiler. The Borland documentation > states "If an invalid multibyte character is encountered, wcstombs returns > (size_t) -1. Otherwise, the function returns the number of bytes modified, > not including the terminating code, if any." > > Regarding the 2 or more byte issue: Both implementations of wcstombs rely > on a compile time quantity for the maximum number of bytes that a > multi-byte character can contain.
{'source': 'Apache Software Foundation Public Mail Archives'}