[ https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625920#comment-13625920 ]
Alexios Giotis commented on FOP-2211: ------------------------------------- Peter (or any other committer), will you commit your (Peter's) patch with the exception of the deleteOnExit() method ? Or do you prefer that I create another (bigger) patch that will not be 100% compatible with the current trunk but will attempt to give an elegant way of handling temp files ? > [PATCH] Fix & improve the handling of temporary files using the new URI > resource resolvers > ------------------------------------------------------------------------------------------ > > Key: FOP-2211 > URL: https://issues.apache.org/jira/browse/FOP-2211 > Project: Fop > Issue Type: Bug > Components: general > Affects Versions: trunk > Reporter: Alexios Giotis > Fix For: trunk > > Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch > > > As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge > of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using > temp files has changed from: > {code} > File tmpFile = File.createTempFile(....); > // Write and read from the file > tmpFile.delete(); > {code} > to: > {code} > File tmpFile = new File(System.getProperty("java.io.tmpdir"), > counterStartingFrom1AsString); > tmpFile.deleteOnExit(); > // Write and read from the file > {code} > This is fine when FOP is executed from the command line (which I guess this > is how most people use it) but it introduces a number of bad side effects for > long running processes that use FOP embedded. > > 1. Different FOP processes can't be executed in parallel on the same system > because creating the same temp file fails. > 2. If the JVM is not normally terminated, the temp files are never deleted > and the next invocation of the JVM fails to run. > 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp > files both on disk and a reference in memory. > There should not be a need to implement a custom resource resolver when using > FOP embedded in order to fix those issues. The default implementation should > work at least as good as it worked in FOP 1.1 or earlier. > Attached are 2 patches, one for XGC and one for FOP that should fix and > improve the handling of at least the temporary files. > For reference, [1] lists some reasons for implementing the new URI resource > resolvers. > [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira