Does anyone have any argument against this change or know why it would
cause any kind of problems? If not, then I'll make this change and check it
in. Speak quickly if you think its not a good thing, because we are moving
towards a release.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Abhijit Savarkar" <[EMAIL PROTECTED]> on 01/20/2000 12:20:25
AM
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: Extending Xerces
Hello,
I am new to Xerces XML parser. I intend to use
SAXParser. Here I implemented my own sax handler
implementing the typical sax callback apis. It works
well.
However I need to read the xml input from a win32
read pipe and not from any disk file. Here I used my
extended/specialized classes as follows to get the
work done :-
1. Use MyInputSource that accepts a file handle as
the input parameter for its ctor. It implements the
make stream by passing this handle to instantiate a
new BinFileInputStream.
2. Use MySAXParser class to derive from SAXParser
and override the parse method to accept FileHandle
as the first input parameter. This overridden method
then calls the normal SAXParser::parse but uses
MyInputSource instantiated with the input FileHandle.
This works out well and without changing any thing
from the xerces library I am able to use pipes as one
of the XML sources.
Now onto some problems. In this scenario I use the
write pipe handle to dump XML data into the pipe on a
separate thread and is read by the SAXParser
simultaneously. I close the write pipe when I am done
with writing XML data. However all this runs into trouble
with XMLPlatformUtils::readFileBuffer method which
throws an exception when the write end of the pipe
is closed as it receives error from ReadFile win32 call
and it generally treats all errors alike and throws an
exception.
Well my observations are as follows
1. The platform specific XMLPlatformUtils methods are
all class static and hence give no opportunity to override
them by deriving my own version.
2. This means I have to change the xerces library code to
incorporate the changes.
I have changed the code locally to monitor the error by
first calling GetLastError() to find out the reason for failure
and if it is ERROR_BROKEN_PIPE (i.e. the other end of the
pipe is closed) then I set the no. of bytes read to 0 and
return; for all other cases I continue throwing the exception.
This works perfectly well and I donot get any more errors.
I would like to know whether these kind of code changes/
patches are acceptable to the xerces source pool or
should I wait for forthcoming releases that have more
interesting things ( like supporting www urls for xml source)
and if so how soon.
Thanks everybody for the audience.
Further information/help/clues will be of great help to me.
Thanks N Rgds
Abhijit Savarkar
--------------------------------
[EMAIL PROTECTED]
--------------------------------
