[ 
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632745#comment-13632745
 ] 

Peter Hancock commented on FOP-2211:
------------------------------------

Fix committed in revision 1468361

Alexios - Thanks for you help and please feel free to post any ideas or code 
for better handling of temp data.
                
> [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

Reply via email to