cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: Cocoon locking files on filesystem
Date Sat, 27 Oct 2001 02:26:01 GMT
Berin Loritsch wrote:

>Darren Gibbons wrote:
>>Hi all,
>>I'm using Tomcat4+Cocoon2rc1a on Windows NT4 Workstation.  I've run into a
>>strange problem when editing XSL files.  After starting up Tomcat, I can
>>edit and save my XSL files without any problems.  However, if I access a
>>page that uses one of these XSL files, Tomcat sometimes "locks" the file,
>>and makes further saving of the file impossible.

>>The odd thing is, it's not always reproducible.  Sometimes I'll be able to
>>perform several rounds of editing and saving before the error shows up.
>>Shutting down and restarting Tomcat clears the error every time.
>>Any ideas?  Any suggestions of IDE's that don't display this behaviour?
>>This makes editing somewhat frustrating after a while.
>An exception is probably being thrown and and caught before the stream is
>closed.  Can someone verify that all streams are closed in a "finally" block?
I have experienced the same problem and now hope to have found the 
culprit. In org.apache.cocoon.components.xslt.XSLTProcessorImpl (CVS 
Version 1.0), check out the function transform() and locate the 
following lines:

>       InputSource is = source.getInputSource();
>       getLogger().debug("XSLTProcessorImpl: starting transform");
>       transformer.transform(new StreamSource(is.getByteStream(),
>                                              is.getSystemId()),
>                             result);

You see the is.getByteStream() call ? It returns an opened InputStream, 
which is not being explicitly closed anywhere near. According to the 
Java Bug Database, a lock is being maintained as long as the InputStream 
remains open - in this case until it is being garbage-collected.

I guess that the sporadic locking of XSLT files arises due to the opened 
InputStream returned by is.getByteStream() is only then being closed 
when the StreamSource object is being garbage-collected. StreamSource 
does not offer any direct method of closing the stream, and the 
semantics of transform() do not imply that the Source is explictly being 
closed by that operation. As I currently cannot test my assumption, it 
would be cool if anyone could test it by turning it into something like this

>       InputSource is = source.getInputSource();
>       InputStream bs = is.getByteStream();
>       getLogger().debug("XSLTProcessorImpl: starting transform");
>       transformer.transform(new StreamSource(bs,
>                                              is.getSystemId()),
>                             result);
>       bs.close();

and give it a try.

Best regards,

Michael Hartle,
Hartle & Klug GbR

To unsubscribe, e-mail:
For additional commands, email:

View raw message