[jira] [Updated] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Hancock updated FOP-2211:
---
Attachment: fop.patch
[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
[jira] [Updated] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
simon steiner updated FOP-2211:
---
Attachment: tempurisimple.patch
Here is version that maintains interface backwards compatibility
[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, 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
[jira] [Updated] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[ https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexis Giotis updated FOP-2211: --- Attachment: fop.patch xgc.patch Patches for XGC https://svn.apache.org/repos/asf/xmlgraphics/commons/trunk@1430286 and FOP https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@1444631 [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: Alexis 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: 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 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
[jira] [Updated] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexis Giotis updated FOP-2211:
---
Description:
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
was:
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:
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 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
[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: Alexis 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
