<snipped some details>
The Problem: At about 1% of our 4650 customers Xalan raises the error: "primary document entity could not be opened". It happens in environments where the XSL-Dokument is at localhost and where the document is on a seperate server. The problem isn't affectet by using UNC-paths or paths containing blanks.
I'm working with Streams: First I use the Win32-API function ifstream( filename, ios::in ) to konvert the file into a stream (1s) because I'd like to use this stream (1s) with the contructor of an XSLTInputSource( 1s ).
But this didn't always work because of a problem with the STL-Streams. Sometimes the internal get-Pointer does not point to the starting position of the stream but to the end! This is a bug of the STL-API and this is why I sort of shake the Stream before I give it to the Contructor of XSLTInputSource. I'm shaking it the following way:
// putting the get-Pointer to the beginning of the buffer
(void) XmlStream.seekg( 0 ); // Then copiing the buffer into a temporary stringstream
stringstream temp;
temp << XmlStream.rdbuf() << ends;
// Because even this isn't enough...
temp.str( temp.str() );
This is how it always works in my environment and in our test environments.
Is anybody here who has the same or similar problem with Xalan/Serces? Can anybody help me to get along with the bug of STL a better way?
I'd be glad to discuss some answers and I am running out of ideas.
Since no one else has replied yet, I'll jump in with some comments.
I have no idea what is going on. But I am very suspicious of your STL-stream problems. I am not aware of bugs in the MS VC++ stream implementation that would cause the need to do things to the stream before using it, so I suspect you have an underlying bug in your own code that you haven't discovered yet.
I assume you are already using VC++ SP5, or you have applied the vc++ stl patches.
Next, I would get the STLPort version of stl (www.stlport.org), and compile that, and use it with your application. STLPort includes its own version of IOStreams, which has better performance than the VC++ one. Also, you can compile STLPort in a debug mode, where it performs various safety checks (eg, array bound checks). Use this, to see if you are breaking the STL container or stream rules somewhere. I would recompile your application, Xerces, and Xalan all with STLPort, so everything is consistent. (Actually, I don't think Xerces uses STL, as I recall, so you might not have to touch it.)
If your application uses multiple threads, review your thread interaction.
Build a debug build of your application and try that at your sites where the problem occurs. Because debug build initializes variables to known values, it often "fixes" errors with missing initialization. This won't identify the problem, but it does give you a clue.
Just some thoughts - I may be off base, but these are the things that come to mind from your description. I do sympathize -- a problem at 1% of your installations can be tough to find.
Don
