[ https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581402#comment-13581402 ]
Alexios Giotis commented on FOP-2211: ------------------------------------- Hi Chris, I don't understand the advantages of such a virtual file system or why would anyone need to isolate the *temp* resources of different tenants that are using a common filesystem. Are you afraid of collision on filenames ? Or that if the application crashes, the temp files will not be deleted ? Anyway, that would need going into more details about the use case and the relevant cloud infrastructure. I will assume that you really have this need. I will wait a few more days in case the initial authors (Peter and Mehdi) have some more input. Then, I will update the 2 patches taking under consideration the comments so far. > [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, 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