Hi Alexis,
The DefaultTempResourceResolver is used by the DefaultResourceResolver
and is suitable for the case when we run FOP from the command line
>... the actual pattern of using temp files has changed from:
>
> File tmpFile = File.createTempFile(....);
> // Write and read from the file
> tmpFile.delete();
>
> to:
> File tmpFile = new File(System.getProperty("java.io.tmpdir"),
> counterStartingFrom1AsString);
> tmpFile.deleteOnExit();
> // Write and read from the file
>
>
> This introduces a number of bad side effects:
> 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.
>
The DefaultTempResourceResolver is used by the DefaultResourceResolver
and is suitable in the case when we run FOP from the command line and
sequentiality at the system level. I agree that the first side effect
is problematic and the URI generator should perhaps add some random
characters or something similiar. The 2nd point and 3rd point are not
an issue when we run FOP from the command line.
When running FOP as part of a long running process I would recommend
creating an implementation of TempResourceResolver that handles the
cleanup: This implementation could return an instance of Resource in
the getResource method that s parametrised with an InputStream that
uses close() to perform the file deletion - you could even decide to
store the temporary data in memory if your requirements make that
feasible.
> I am also tempted to delete the org.apache.xmlgraphics.io.Resource and change
> in ResourceResolver the
> Resource getResource(URI uri)
> to
> InputStream getInputStream(URI uri)
>
>
> Although in [1] there is a reason for having it, in practice the "type" is
> used nowhere.
>
Although the type property is not used yet, it was introduced as a way
of being able to set something like a mime type on a resource without
having to encode that in the URL. For example, if FOP needed to be
able to determine the type of font that a resource represented it
would be better to declare this as a property, rather than perhaps
using a pseudo file extension. This was looslely inspired by the HTTP
protocol that uses the 'content-type header field to identify the
content type of a resonse.
Please ask me to expand on any of my explanations if you require more detail.
Thanks,
Pete
