[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13633353#comment-13633353
]
Alexios Giotis commented on FOP-2211:
-
Peter, thanks for committing this.
Vincent, I have not started working since the patch addresses my runtime issues
and I was not sure if there was an agreement on changing that. After an
official release, it will be much harder to improve the handling of temporary
resources as it's part of the public API. So, I will give it a try next week
and if it looks good, I will post the patches for FOP and XGC.
> [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
>Assignee: Peter Hancock
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=13633107#comment-13633107
]
Vincent Hennebert commented on FOP-2211:
To elaborate a bit, I think we now all agree that temporary files shouldn't be
handled by the URI framework. Those two issues are orthogonal.
The suggestion would be to scrape the tmp:// scheme from the URI framework and
to replace it with a system that manages temporary resources. A good use case
would be the PSDocumentHandler that, when optimize-resources is set to true,
stores the output in a temp file in order to re-arrange it in a second pass.
Instead of storing the whole output in one big temp file, it could be split
into several parts each stored in a different file, and then put together. A
new temporary resource manager should allow to easily do that.
Alexios, if you feel like exploring this idea further (you might have started
already?), then you would be most welcome, and I'll try and spare cycles to
review your work.
Thanks,
Vincent
> [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
>Assignee: Peter Hancock
> 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] [Comment Edited] (FOP-2221) [PATCH] Make overflow messages easier to read and fix wrong/ missing messages
[ https://issues.apache.org/jira/browse/FOP-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633014#comment-13633014 ] Vincent Hennebert edited comment on FOP-2221 at 4/16/13 5:05 PM: - Not there yet I'm afraid. See attached file: error message wrongly indicates that the extent is overflowed. was (Author: vhennebert): Error message wrongly indicates that the extent is overflowed. > [PATCH] Make overflow messages easier to read and fix wrong/ missing messages > - > > Key: FOP-2221 > URL: https://issues.apache.org/jira/browse/FOP-2221 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: overflow-message.fo, overflowsmessage2.patch, > overflowsmessage5.patch > > > Users find it difficult to read over flow messages, patch shows element name > and easier to read message. -- 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-2221) [PATCH] Make overflow messages easier to read and fix wrong/ missing messages
[ https://issues.apache.org/jira/browse/FOP-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2221: --- Attachment: overflow-message.fo Error message wrongly indicates that the extent is overflowed. > [PATCH] Make overflow messages easier to read and fix wrong/ missing messages > - > > Key: FOP-2221 > URL: https://issues.apache.org/jira/browse/FOP-2221 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: overflow-message.fo, overflowsmessage2.patch, > overflowsmessage5.patch > > > Users find it difficult to read over flow messages, patch shows element name > and easier to read message. -- 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
Re: svn commit: r1468367 - /xmlgraphics/fop/trunk/status.xml
Hi Pete, What was the purpose of the property change on status.xml? Thanks, Chris On 16/04/2013 12:09, phanc...@apache.org wrote: Author: phancock Date: Tue Apr 16 11:09:04 2013 New Revision: 1468367 URL: http://svn.apache.org/r1468367 Log: FOP-2211: fixed in previous Modified: xmlgraphics/fop/trunk/status.xml (props changed) Propchange: xmlgraphics/fop/trunk/status.xml -- dummyproperty = 1 - To unsubscribe, e-mail: fop-commits-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-commits-h...@xmlgraphics.apache.org
[jira] [Closed] (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 closed FOP-2211.
--
Resolution: Fixed
Assignee: Peter Hancock
> [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
>Assignee: Peter Hancock
> 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] [Commented] (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: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
[jira] [Updated] (FOP-2237) [PATCH]Clicking zoom-in or zoom-out buttons in preview screen should cause NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Orolin updated FOP-2237: -- Summary: [PATCH]Clicking zoom-in or zoom-out buttons in preview screen should cause NullPointerException (was: [PATCH]Zoom in "preview screen" should cause NullPointerException) > [PATCH]Clicking zoom-in or zoom-out buttons in preview screen should cause > NullPointerException > --- > > Key: FOP-2237 > URL: https://issues.apache.org/jira/browse/FOP-2237 > Project: Fop > Issue Type: Bug > Components: awt renderer >Affects Versions: trunk > Environment: Operating System: Windows > Platform: PC >Reporter: Peter Orolin > Labels: patch > Attachments: patch.diff > > Original Estimate: 3h > Remaining Estimate: 3h > > Zoom in "preview screen" should cause NullPointerException, because of > incorrect use of synchronized in class > org.apache.fop.render.awt.viewer.PreviewPanel. > Method PreviewPanel.reload() is synchronized, but it creates new Thread, > which is not under synchronized control. Sometimes, when it is later run > method PreviewPanel.showPage(), it finishes with NullPointerException (array > pagePanels is initialized, but objects in the array not -- see > PreviewPanel.ShowPageImage.run statement pagePanels[pg - > firstPage].setPage(pg);) -- 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-2237) [PATCH]Zoom in "preview screen" should cause NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Orolin updated FOP-2237: -- Description: Zoom in "preview screen" should cause NullPointerException, because of incorrect use of synchronized in class org.apache.fop.render.awt.viewer.PreviewPanel. Method PreviewPanel.reload() is synchronized, but it creates new Thread, which is not under synchronized control. Sometimes, when it is later run method PreviewPanel.showPage(), it finishes with NullPointerException (array pagePanels is initialized, but objects in the array not -- see PreviewPanel.ShowPageImage.run statement pagePanels[pg - firstPage].setPage(pg);) was: Zoom in "preview screen" should cause NullPointerException, because of incorrect use of synchronized in class org.apache.fop.render.awt.viewer.PreviewPanel. Method PreviewPanel.reload() is synchronized, but it creates new Thread, which is not under synchronized control. Sometimes, when it is later run method PreviewPanel.showPage(), it finishes with NullPointerException (array pagePanels is initialized, but objects in the array not -- see ShowPageImage.run statement pagePanels[pg - firstPage].setPage(pg);) > [PATCH]Zoom in "preview screen" should cause NullPointerException > - > > Key: FOP-2237 > URL: https://issues.apache.org/jira/browse/FOP-2237 > Project: Fop > Issue Type: Bug > Components: awt renderer >Affects Versions: trunk > Environment: Operating System: Windows > Platform: PC >Reporter: Peter Orolin > Labels: patch > Attachments: patch.diff > > Original Estimate: 3h > Remaining Estimate: 3h > > Zoom in "preview screen" should cause NullPointerException, because of > incorrect use of synchronized in class > org.apache.fop.render.awt.viewer.PreviewPanel. > Method PreviewPanel.reload() is synchronized, but it creates new Thread, > which is not under synchronized control. Sometimes, when it is later run > method PreviewPanel.showPage(), it finishes with NullPointerException (array > pagePanels is initialized, but objects in the array not -- see > PreviewPanel.ShowPageImage.run statement pagePanels[pg - > firstPage].setPage(pg);) -- 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] [Comment Edited] (FOP-2237) [PATCH]Zoom in "preview screen" should cause NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632668#comment-13632668 ] Peter Orolin edited comment on FOP-2237 at 4/16/13 8:54 AM: Attachment patch.diff has been added. Concurrent problem was fixed was (Author: orol): Attachment patch.diff has been added > [PATCH]Zoom in "preview screen" should cause NullPointerException > - > > Key: FOP-2237 > URL: https://issues.apache.org/jira/browse/FOP-2237 > Project: Fop > Issue Type: Bug > Components: awt renderer >Affects Versions: trunk > Environment: Operating System: Windows > Platform: PC >Reporter: Peter Orolin > Labels: patch > Attachments: patch.diff > > Original Estimate: 3h > Remaining Estimate: 3h > > Zoom in "preview screen" should cause NullPointerException, because of > incorrect use of synchronized in class > org.apache.fop.render.awt.viewer.PreviewPanel. > Method PreviewPanel.reload() is synchronized, but it creates new Thread, > which is not under synchronized control. Sometimes, when it is later run > method PreviewPanel.showPage(), it finishes with NullPointerException (array > pagePanels is initialized, but objects in the array not -- see > ShowPageImage.run statement pagePanels[pg - firstPage].setPage(pg);) -- 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-2237) [PATCH]Zoom in "preview screen" should cause NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Orolin updated FOP-2237: -- Attachment: patch.diff Attachment patch.diff has been added > [PATCH]Zoom in "preview screen" should cause NullPointerException > - > > Key: FOP-2237 > URL: https://issues.apache.org/jira/browse/FOP-2237 > Project: Fop > Issue Type: Bug > Components: awt renderer >Affects Versions: trunk > Environment: Operating System: Windows > Platform: PC >Reporter: Peter Orolin > Labels: patch > Attachments: patch.diff > > Original Estimate: 3h > Remaining Estimate: 3h > > Zoom in "preview screen" should cause NullPointerException, because of > incorrect use of synchronized in class > org.apache.fop.render.awt.viewer.PreviewPanel. > Method PreviewPanel.reload() is synchronized, but it creates new Thread, > which is not under synchronized control. Sometimes, when it is later run > method PreviewPanel.showPage(), it finishes with NullPointerException (array > pagePanels is initialized, but objects in the array not -- see > ShowPageImage.run statement pagePanels[pg - firstPage].setPage(pg);) -- 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-2237) [PATCH]Zoom in "preview screen" should cause NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Orolin updated FOP-2237: -- Description: Zoom in "preview screen" should cause NullPointerException, because of incorrect use of synchronized in class org.apache.fop.render.awt.viewer.PreviewPanel. Method PreviewPanel.reload() is synchronized, but it creates new Thread, which is not under synchronized control. Sometimes, when it is later run method PreviewPanel.showPage(), it finishes with NullPointerException (array pagePanels is initialized, but objects in the array not -- see ShowPageImage.run statement pagePanels[pg - firstPage].setPage(pg);) was: [PATCH]Zoom in "preview screen" should cause NullPointerException, because of incorrect use of synchronized in class org.apache.fop.render.awt.viewer.PreviewPanel. Method PreviewPanel.reload() is synchronized, but it creates new Thread, which is not under synchronized control. Sometimes, when it is later run method PreviewPanel.showPage(), it finishes with NullPointerException (array pagePanels is initialized, but objects in the array not -- see ShowPageImage.run statement pagePanels[pg - firstPage].setPage(pg);) Summary: [PATCH]Zoom in "preview screen" should cause NullPointerException (was: Zoom in "preview screen" should cause NullPointerException) > [PATCH]Zoom in "preview screen" should cause NullPointerException > - > > Key: FOP-2237 > URL: https://issues.apache.org/jira/browse/FOP-2237 > Project: Fop > Issue Type: Bug > Components: awt renderer >Affects Versions: trunk > Environment: Operating System: Windows > Platform: PC >Reporter: Peter Orolin > Labels: patch > Original Estimate: 3h > Remaining Estimate: 3h > > Zoom in "preview screen" should cause NullPointerException, because of > incorrect use of synchronized in class > org.apache.fop.render.awt.viewer.PreviewPanel. > Method PreviewPanel.reload() is synchronized, but it creates new Thread, > which is not under synchronized control. Sometimes, when it is later run > method PreviewPanel.showPage(), it finishes with NullPointerException (array > pagePanels is initialized, but objects in the array not -- see > ShowPageImage.run statement pagePanels[pg - firstPage].setPage(pg);) -- 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] [Created] (FOP-2237) Zoom in "preview screen" should cause NullPointerException
Peter Orolin created FOP-2237: - Summary: Zoom in "preview screen" should cause NullPointerException Key: FOP-2237 URL: https://issues.apache.org/jira/browse/FOP-2237 Project: Fop Issue Type: Bug Components: awt renderer Affects Versions: trunk Environment: Operating System: Windows Platform: PC Reporter: Peter Orolin [PATCH]Zoom in "preview screen" should cause NullPointerException, because of incorrect use of synchronized in class org.apache.fop.render.awt.viewer.PreviewPanel. Method PreviewPanel.reload() is synchronized, but it creates new Thread, which is not under synchronized control. Sometimes, when it is later run method PreviewPanel.showPage(), it finishes with NullPointerException (array pagePanels is initialized, but objects in the array not -- see ShowPageImage.run statement pagePanels[pg - firstPage].setPage(pg);) -- 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
