|
Dane,
Understood. However, what I am referring to is the source code to
the parse method, not the code you attached. I understand that the code
you attached will do the trick, and it is what I am going to use for a
workaround for now, but what I am asking about is the actual Xerces source for
the parse method, which does close the file on a clean parse. When an
Exception is thrown, however, it does not appear to close the file. This
then is a difference in postconditions of the parse method, and my question
refers to whether this is desirable to have two different potential states after
the method executes. I would guess that we would want either a file
closed or a file open state at the return of control from the parse method, but
not the possibility of either.
Brad
Because you are closing the InputStream in the finally block
the stream will be closed whether an exception is thrown or not.
----- Original Message -----
Sent: Saturday, March 03, 2001 3:08
PM
Subject: RE: Explicit file
closing
Thanks for the recommendation! I will do this for the time
being. I still am curious as to when, in an Exception situation, the
file will ever be closed. If exiting the parse method cleanly closes
the file, I would expect that in an Exception situation we might want the
same thing -- it lends consistency to the postconditions of the
method. Any thoughts?
Brad
Yes, what he said.
:)
Early versions of XML4j closed the stream automatically and that
was
a real pain when you wanted to keep it
open.
Chad
Loder
At 11:49 AM 3/3/2001 -0500, you wrote:
Close the file
yourself in a finally block.
Example:
InputStream someStream
= null;
try
{
someStream = new
BufferedInputStream( new FileInputStream( "someFile" ) );// Any
variation should work
parser.parse( new InputSource( someStream ) );
}
catch( SAXException sax ){ /* handle
exception */ }
finally
{
if( null !=
someStream )
try
{
someStream.close();
}
catch( IOException io
){}// ignore because parser may have closed it if parsing was
successfull
}
Dane
Foster
Equity Technology Group, Inc
http://www.equitytg.com.
954.360.9800
- ----- Original Message -----
- From: Roytman,
Alex
- To: '[EMAIL PROTECTED]'
- Sent: Friday, March 02, 2001 4:32 PM
- Subject: RE: Explicit file closing
- I noticed also that if an exception happens while parsing a file
with external entity
- the entity file will remain open (main file will be properly
closed).
- -----Original Message-----
- From: Brad O'Hearne [mailto:[EMAIL PROTECTED]]
- Sent: Friday, March 02, 2001 1:06 PM
- To: [email protected];
[EMAIL PROTECTED]
- Subject: RE: Explicit file closing
- Hey all,
- I hate to be redundant here :-), but I am hoping the key to
getting feedback
- is persistence. :-) In looking through the source code, I am
not seeing
- where the SAXParser is being closed when an exception is thrown
out of the
- parsing of the XML file. (i.e. the parse(String uri) method
in the
- XMLReader class is interrupted by the throwing of an
Exception). This is
- directly causing a problem in my application because the XMLReader
is not
- letting go of the file when this Exception is thrown, which
prevents further
- file operations (like moving the file). If I am wrong in
this observation,
- if someone would please correct me, I would be greatly
appreciative. If I
- am right, then the file either needs to be closed when the
Exception is
- thrown, OR there needs to be a method available that allows
explicit closing
- of the XML file.
- Thanks!
- BradO
- -----Original Message-----
- From: Brad O'Hearne [mailto:[EMAIL PROTECTED]]
- Sent: Tuesday, February 27, 2001 11:04 PM
- To: [EMAIL PROTECTED];
[email protected]
- Subject: RE: Explicit file closing
- Has anyone been able to verify this problem, or have any ideas on
the
- solution?
- BradO
- -----Original Message-----
- From: Brad O'Hearne [mailto:[EMAIL PROTECTED]]
- Sent: Friday, February 23, 2001 7:48 PM
- To: [EMAIL PROTECTED];
[email protected]
- Subject: RE: Explicit file closing
- I was looking through the source on this in the
- org.apache.xerces.framework.XMLParser class, and it appears that
the
- parse(String systemId) method does not close the InputSource if an
Exception
- is thrown -- it appears parsing has to end gracefully for this to
happen.
- This would also be consistent with the results I am getting below
(if an
- Exception, the file is locked, if it ends gracefully, the file is
free).
- Perhaps I am overlooking something, but the parse method isn't
inside a
- try-catch. If I have read this correctly, I would throw the
call to the
- parse(InputSource is) that resides inside the parse(String
systemId) method
- inside a try-catch block with a finally that closes the
InputSource. Let me
- know if this seems right -- perhaps I missed something.
- Thanks in advance,
- BradO
- -----Original Message-----
- From: Brad O'Hearne [mailto:[EMAIL PROTECTED]]
- Sent: Friday, February 23, 2001 6:55 PM
- To: [EMAIL PROTECTED]
- Subject: Explicit file closing
- Hello all,
- I ran into an interesting problem tonight. I am using a SAX2
parser. My
- app moves my xml file to a new directory immediately following
parsing, or
- if parsing is aborted after a SAXException is thrown. I am
getting an
- access conflict on the file trying to move my file following a
SAXException
- being thrown and parsing being aborted. I have checked the
XMLReader
- interface and noticed that there are no methods declared for
explicitly
- closing the underlying file. Is there some way for the app
to explicitly
- control the closing of the file, and if not, should this be
added? (I guess
- another question is when exactly is the file being closed
now?)
- Thanks in advance for help!
- BradO
- ---------------------------------------------------------------------
- To unsubscribe, e-mail:
[EMAIL PROTECTED]
- For additional commands, e-mail:
[EMAIL PROTECTED]
- ---------------------------------------------------------------------
- To unsubscribe, e-mail:
[EMAIL PROTECTED]
- For additional commands, e-mail:
[EMAIL PROTECTED]
- ---------------------------------------------------------------------
- To unsubscribe, e-mail:
[EMAIL PROTECTED]
- For additional commands, e-mail:
[EMAIL PROTECTED]
|
