You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Colin Paul Adams <co...@colina.demon.co.uk> on 2003/01/23 12:31:46 UTC
Bug 15928 not fixed in latest nightly builds
I noticed today that my code using LocalFileFormatTarget with
DOMWriter::writeNode was apparently working (writeNode returns true), but the file was empty.
Inspecting the source code (nightly build of 11th Jan), I see there is
a comment about a bug (15928) for this very problem. Well, it appears
not to be fixed. I reverted to 2.1.0 and my code works again.
If I can remember, I shall go to Bugzilla tonight, when I can get
online again. But I'm posting this message just in case I forget.
--
Colin Paul Adams
Preston Lancashire
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Tinny" == Tinny Ng <tn...@ca.ibm.com> writes:
Tinny> I think I should fix the code and move the method
Tinny> "LocalFileFormatTarget::flushBuffer()" from private to
Tinny> public so that caller can actively flush the buffer if
Tinny> needed.
Yes please. It's causing me problems at the moment, and I can envision
other circumstances when it would be necessary.
--
Colin Paul Adams
Preston Lancashire
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: When to delete nodes. Was: Bug 15928 not fixed in latest nightly
builds
Posted by Gareth Reakes <ga...@decisionsoft.com>.
Hi,
you can never delete the DOMNodes. You can call release on them to
make the memory they are using be recycled. The memory from the DOMNodes
is owned by the document. When you delete the document the memory from the
nodes is freed.
Gareth
On 25 Jan 2003, Colin Paul Adams wrote:
> >>>>> "Colin" == Colin Paul Adams <co...@colina.demon.co.uk> writes:
>
> Tinny> In the meantime may be you can check why the "local_file"
> Tinny> is not destroyed in your Eiffel program.
>
> Colin> Oh, I know why that is. I've been putting off facing up to
> Colin> analysing how to deal with when to destroy objects (project
> Colin> is still beta). I guess now is the time.
>
> So that was easily fixed.
>
> What I am not clear about, is when it is safe to delete the nodes in a
> DOMDocument structure. Do these all have to be deleted individually,
> or does deleting the owning DOMDocument or DOMDocumentFragment
> suffice? Does it make a difference if the document is created by a
> DOMBuilder or by a call to createDocument?
>
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
When to delete nodes. Was: Bug 15928 not fixed in latest nightly builds
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Colin" == Colin Paul Adams <co...@colina.demon.co.uk> writes:
Tinny> In the meantime may be you can check why the "local_file"
Tinny> is not destroyed in your Eiffel program.
Colin> Oh, I know why that is. I've been putting off facing up to
Colin> analysing how to deal with when to destroy objects (project
Colin> is still beta). I guess now is the time.
So that was easily fixed.
What I am not clear about, is when it is safe to delete the nodes in a
DOMDocument structure. Do these all have to be deleted individually,
or does deleting the owning DOMDocument or DOMDocumentFragment
suffice? Does it make a difference if the document is created by a
DOMBuilder or by a call to createDocument?
--
Colin Paul Adams
Preston Lancashire
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Tinny" == Tinny Ng <tn...@ca.ibm.com> writes:
Tinny> Colin, The data got flushed in LocalFileFormatTarget
Tinny> destructor. So I guess the object "local_file" is not
Tinny> destroyed in your Eiffel program and thus problem; while in
Tinny> C++ it is destroyed when going out of scope.
OK, that explains it.
Tinny> In the meantime may be you can check why the "local_file"
Tinny> is not destroyed in your Eiffel program.
Oh, I know why that is. I've been putting off facing up to analysing
how to deal with when to destroy objects (project is still beta). I
guess now is the time.
--
Colin Paul Adams
Preston Lancashire
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Tinny Ng <tn...@ca.ibm.com>.
Colin,
The data got flushed in LocalFileFormatTarget destructor. So I guess the
object "local_file" is not destroyed in your Eiffel program and thus
problem; while in C++ it is destroyed when going out of scope.
I think I should fix the code and move the method
"LocalFileFormatTarget::flushBuffer()" from private to public so that caller
can actively flush the buffer if needed.
In the meantime may be you can check why the "local_file" is not destroyed
in your Eiffel program.
Tinny
----- Original Message -----
From: "Colin Paul Adams" <co...@colina.demon.co.uk>
To: <xe...@xml.apache.org>
Sent: Friday, January 24, 2003 10:50 AM
Subject: Re: Bug 15928 not fixed in latest nightly builds
> >>>>> "Tinny" == Tinny Ng <tn...@ca.ibm.com> writes:
>
> >> Would you like me to write the equivalent pure C++ program?
> Tinny> Yes please. Appreciated.
>
> Well, I've done so, and there is no difference between 2.1.0 and 11th
> January nightly build!
> Of course, the equivalent program is not IDENTICAL to my Eiffel
> implementation (as it consists of several layers of bridging), but it
> ought to be the same.
>
> Now I look at the source code for writeChars, and immediately noticed
> that there was no flushing of the data buffer there. When I look at
> 2.1.0 I instead see a call to writeBufferToFile.
>
> So I imagine that for some reason the buffers are getting flushed at
> some time with my C++ equivalent, but not in the case of the Eiffel
> bridging implementation.
>
> Can you suggest a line of attack for this problem please?
>
> First, here's the code of the C++ equivalent:
>
> #include <xercesc/dom/DOM.hpp>
> #include <xercesc/util/PlatformUtils.hpp>
> #include <xercesc/util/XMLString.hpp>
> #include <xercesc/framework/LocalFileFormatTarget.hpp>
>
> XERCES_CPP_NAMESPACE_USE
>
> main ()
> {
>
> XMLPlatformUtils::Initialize();
>
> DOMImplementation * impl =
DOMImplementationRegistry::getDOMImplementation ( XMLString::transcode (
"XML 1.0 Core 3.0 LS" ) );
>
> DOMDocument * document = impl->createDocument ( XMLString::transcode (
"urn:colina.demon.co.uk:domwriter-test-one" ), XMLString::transcode (
"test:document" ), 0 ) ;
>
> DOMElement * document_element = document->getDocumentElement ();
> document_element->setAttributeNS ( XMLString::transcode (
"http://www.w3.org/2000/xmlns/" ), XMLString::transcode ( "xmlns:test" ),
> XMLString::transcode (
"urn:colina.demon.co.uk:domwriter-test-one" ) );
>
> DOMElement * sub_element = document->createElement (
XMLString::transcode ( "doNotPrint" ) );
> document_element->appendChild ( sub_element );
>
> DOMProcessingInstruction * pi = document->createProcessingInstruction
( XMLString::transcode ( "target" ), XMLString::transcode ( "some target
data" ) );
> document->appendChild ( pi );
>
> DOMWriter * writer = static_cast<DOMImplementationLS *> (
impl )->createDOMWriter ();
> writer->setFeature( XMLString::transcode ( "format-pretty-print" ),
true );
>
> LocalFileFormatTarget local_file ( XMLString::transcode (
"/tmp/test.xml" ) );
>
> writer->writeNode ( &local_file, *document );
> writer->release ();
>
> XMLPlatformUtils::Terminate();
> }
>
> Now for the effective differences with the Eiffel implementation:
>
> 1) I have no call to release or Terminate (I have still to consider
> how best to do these automatically - as my Eiffel code is supposed to
> be pure DOM, with multiple possible implementations). But the above
> code works even if you comment these out.
> 2) Rather than calling XMLString::transcode, I create a UTF-8
> transcoder, and use that (as pure ascii is a subset of UTF-8).
>
> BTW the same code, if writing to StdOutFormatTarget, or
> MemBufFormatTarget, works.
>
> --
> Colin Paul Adams
> Preston Lancashire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Tinny" == Tinny Ng <tn...@ca.ibm.com> writes:
>> Would you like me to write the equivalent pure C++ program?
Tinny> Yes please. Appreciated.
Well, I've done so, and there is no difference between 2.1.0 and 11th
January nightly build!
Of course, the equivalent program is not IDENTICAL to my Eiffel
implementation (as it consists of several layers of bridging), but it
ought to be the same.
Now I look at the source code for writeChars, and immediately noticed
that there was no flushing of the data buffer there. When I look at
2.1.0 I instead see a call to writeBufferToFile.
So I imagine that for some reason the buffers are getting flushed at
some time with my C++ equivalent, but not in the case of the Eiffel
bridging implementation.
Can you suggest a line of attack for this problem please?
First, here's the code of the C++ equivalent:
#include <xercesc/dom/DOM.hpp>
#include <xercesc/util/PlatformUtils.hpp>
#include <xercesc/util/XMLString.hpp>
#include <xercesc/framework/LocalFileFormatTarget.hpp>
XERCES_CPP_NAMESPACE_USE
main ()
{
XMLPlatformUtils::Initialize();
DOMImplementation * impl = DOMImplementationRegistry::getDOMImplementation ( XMLString::transcode ( "XML 1.0 Core 3.0 LS" ) );
DOMDocument * document = impl->createDocument ( XMLString::transcode ( "urn:colina.demon.co.uk:domwriter-test-one" ), XMLString::transcode ( "test:document" ), 0 ) ;
DOMElement * document_element = document->getDocumentElement ();
document_element->setAttributeNS ( XMLString::transcode ( "http://www.w3.org/2000/xmlns/" ), XMLString::transcode ( "xmlns:test" ),
XMLString::transcode ( "urn:colina.demon.co.uk:domwriter-test-one" ) );
DOMElement * sub_element = document->createElement ( XMLString::transcode ( "doNotPrint" ) );
document_element->appendChild ( sub_element );
DOMProcessingInstruction * pi = document->createProcessingInstruction ( XMLString::transcode ( "target" ), XMLString::transcode ( "some target data" ) );
document->appendChild ( pi );
DOMWriter * writer = static_cast<DOMImplementationLS *> ( impl )->createDOMWriter ();
writer->setFeature( XMLString::transcode ( "format-pretty-print" ), true );
LocalFileFormatTarget local_file ( XMLString::transcode ( "/tmp/test.xml" ) );
writer->writeNode ( &local_file, *document );
writer->release ();
XMLPlatformUtils::Terminate();
}
Now for the effective differences with the Eiffel implementation:
1) I have no call to release or Terminate (I have still to consider
how best to do these automatically - as my Eiffel code is supposed to
be pure DOM, with multiple possible implementations). But the above
code works even if you comment these out.
2) Rather than calling XMLString::transcode, I create a UTF-8
transcoder, and use that (as pure ascii is a subset of UTF-8).
BTW the same code, if writing to StdOutFormatTarget, or
MemBufFormatTarget, works.
--
Colin Paul Adams
Preston Lancashire
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Tinny Ng <tn...@ca.ibm.com>.
> Would you like me to write the equivalent pure C++ program?
Yes please. Appreciated.
Tinny
----- Original Message -----
From: "Colin Paul Adams" <co...@colina.demon.co.uk>
To: <xe...@xml.apache.org>
Sent: Thursday, January 23, 2003 4:07 PM
Subject: Re: Bug 15928 not fixed in latest nightly builds
> >>>>> "Tinny" == Tinny Ng <tn...@ca.ibm.com> writes:
>
> Tinny> It may not be related to 15928 then. Have you set an error
> Tinny> handler to the DOMWriter for handling the error from
>
> No. Should I? writeNode returns true.
>
> Tinny> serializing? Or can you please post your xml document or
> Tinny> program for further investigation?
>
> The document is built on the fly, using DOM calls.
>
> The program is in Eiffel (My program is a test program for the Eiffel
> wrapper I have written around the Xerces implementation of the DOM).
> Would you like me to write the equivalent pure C++ program? I can do
> it tomorrow, if so.
> --
> Colin Paul Adams
> Preston Lancashire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Tinny" == Tinny Ng <tn...@ca.ibm.com> writes:
Tinny> It may not be related to 15928 then. Have you set an error
Tinny> handler to the DOMWriter for handling the error from
No. Should I? writeNode returns true.
Tinny> serializing? Or can you please post your xml document or
Tinny> program for further investigation?
The document is built on the fly, using DOM calls.
The program is in Eiffel (My program is a test program for the Eiffel
wrapper I have written around the Xerces implementation of the DOM).
Would you like me to write the equivalent pure C++ program? I can do
it tomorrow, if so.
--
Colin Paul Adams
Preston Lancashire
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Tinny Ng <tn...@ca.ibm.com>.
It may not be related to 15928 then. Have you set an error handler to the
DOMWriter for handling the error from serializing? Or can you please post
your xml document or program for further investigation?
Tinny
----- Original Message -----
From: "Colin Paul Adams" <co...@colina.demon.co.uk>
To: <xe...@xml.apache.org>
Sent: Thursday, January 23, 2003 2:23 PM
Subject: Re: Bug 15928 not fixed in latest nightly builds
> I just get an empty file (the file is created, but with zero size).
> Works properly with 2.1.0.
> --
> Colin Paul Adams
> Preston Lancashire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
I just get an empty file (the file is created, but with zero size).
Works properly with 2.1.0.
--
Colin Paul Adams
Preston Lancashire
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Bug 15928 not fixed in latest nightly builds
Posted by Tinny Ng <tn...@ca.ibm.com>.
Colin,
Can you describe in more details what is not working?
I've tried the DOMPrint from the nightly build by specifying a folder name
as the file name for LocalFieFormatTarget, and I can get the following
error:
E:\xmltest>dir
Volume in drive E is New Volume
Volume Serial Number is 0CA3-37F0
Directory of E:\xmltest
01/23/2003 02:04p <DIR> .
01/23/2003 02:04p <DIR> ..
01/23/2003 01:48p <DIR> results
E:\xmltest>domprint -wfile=results e:\xerces_c_dev\samples\data\personal.xml
An error occurred during creation of output transcoder. Msg is:
Could not open file: results
Tinny
----- Original Message -----
From: "Colin Paul Adams" <co...@colina.demon.co.uk>
To: <xe...@xml.apache.org>
Sent: Thursday, January 23, 2003 6:31 AM
Subject: Bug 15928 not fixed in latest nightly builds
> I noticed today that my code using LocalFileFormatTarget with
> DOMWriter::writeNode was apparently working (writeNode returns true), but
the file was empty.
> Inspecting the source code (nightly build of 11th Jan), I see there is
> a comment about a bug (15928) for this very problem. Well, it appears
> not to be fixed. I reverted to 2.1.0 and my code works again.
>
> If I can remember, I shall go to Bugzilla tonight, when I can get
> online again. But I'm posting this message just in case I forget.
> --
> Colin Paul Adams
> Preston Lancashire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org