DO NOT REPLY [Bug 4496] New: - Result files from transformation sometimes held open

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4496>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4496

Result files from transformation sometimes held open

           Summary: Result files from transformation sometimes held open
           Product: XalanJ2
           Version: CurrentCVS
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: org.apache.xalan.serialize
        AssignedTo: xalan-dev@xml.apache.org
        ReportedBy: curcuru@apache.org


This is an intermittent bug that seems to have become prevalent in the past 
couple of weeks.  Rarely, when attempting to access the output file of a 
transformation shortly after having performed the transformation, the file will 
be locked an unaccessible.
I've been reproducing this on W2K SP2 "JDK J2RE 1.3.0 IBM build cn130-20010207 
(JIT enabled: jitc)" xml-xalan CVS 29-Oct-01 AM by running:

cd xml-xalan/test
build all alltest

The symptom is that one or two random tests in each of the conf runs (using 
different flavors) will fail when attempting to check the output file like so:
<message level="60">executing with: inputName=tests\conf\axes\axes25.xsl 
xmlName=tests\conf\axes\axes25.xml outputName=results-
alltest\file\axes\axes25.out goldName=tests\conf-gold\axes\axes25.out 
flavor=trax.file</message>
<arbitrary level="10"><![CDATA[
XHTFileCheckService threw
java.io.IOException: The process cannot access the file because it is being 
used by another process
java.io.IOException: The process cannot access the file because it is being 
used by another process
	at java.io.Win32FileSystem.canonicalize(Native Method)
	at java.io.File.getCanonicalPath(File.java:442)
	at org.apache.qetest.xsl.XHTFileCheckService.check
(XHTFileCheckService.java:176)
	at org.apache.qetest.xsl.XHTFileCheckService.check
(XHTFileCheckService.java:254)
	at org.apache.qetest.xsl.StylesheetTestlet.execute
(StylesheetTestlet.java:217)
	at org.apache.qetest.xsl.StylesheetTestletDriver.processFileList
(StylesheetTestletDriver.java:414)
	at org.apache.qetest.xsl.StylesheetTestletDriver.processInputDir
(StylesheetTestletDriver.java:370)
	at org.apache.qetest.xsl.StylesheetTestletDriver.runTestCases
(StylesheetTestletDriver.java:259)
	at org.apache.qetest.TestImpl.runTest(TestImpl.java:241)
	at org.apache.qetest.xsl.XSLProcessorTestBase.doMain
(XSLProcessorTestBase.java:768)
	at org.apache.qetest.xsl.StylesheetTestletDriver.main
(StylesheetTestletDriver.java:945)
	at java.lang.reflect.Method.invoke(Native Method)
	at org.apache.qetest.QetestUtils.main(QetestUtils.java:301)

]]></arbitrary>
<fileCheck level="40"
reference="tests\conf-gold\axes\axes25.out"
reportedBy="XHTFileCheckService"
actual="results-alltest\file\axes\axes25.out"
>

Manually checking the axes25.out file shows that the test did pass; however 
when the automated fileChecker utility attempted to verify the actual output 
file, it appears it couldn't open it.
This very rarely also causes problems in some API tests as well, with the same 
symptoms.