[jira] [Updated] (ODFTOOLKIT-413) Document corrupted after copying a sheet including a chart into new spreadsheet
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-413: --- Attachment: SimpleAPI_DuplicatedManifestEntriesTest.diff SpreadsheetWithChart.ods A test case with minor fixes for Simple API. Diff created by Netbeans including already the test document, which was for convenience explicitly added as well. In the diff the pom.xml of the Simple API was changed to update the maven-surefire-plugin to allow me starting only a single test method of a test file from the context menu in Netbeans (avoiding the usage of @Ignore tags as done previously) > Document corrupted after copying a sheet including a chart into new > spreadsheet > --- > > Key: ODFTOOLKIT-413 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-413 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Reporter: Svante Schubert >Assignee: Svante Schubert > Labels: test > Attachments: SimpleAPI_DuplicatedManifestEntriesTest.diff, > SpreadsheetWithChart.ods > > > After copying a sheet including a chart into new spreadsheet the document is > corrupt and have to be repaired by LibreOffice5. > The reason is that there are multiple manifest entries for the same file > within the ODF package, as the validator reveals: see > http://odf-validator.rhcloud.com > I have created a test environment for the Simple API, which copies all > dependent files of the sheet aside of the sheet (the table) itself. > In addition I have fixed in the test scenario already a minor bug in the > Simple API, where attributes without namespaces (an issue of the original > document) can not be created - an additional fix for this side problem will > be in ODFDOM. > The complete fix likely only affects ODFDOM API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ODFTOOLKIT-413) Document corrupted after copying a sheet including a chart into new spreadsheet
Svante Schubert created ODFTOOLKIT-413: -- Summary: Document corrupted after copying a sheet including a chart into new spreadsheet Key: ODFTOOLKIT-413 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-413 Project: ODF Toolkit Issue Type: Bug Components: odfdom Reporter: Svante Schubert Assignee: Svante Schubert After copying a sheet including a chart into new spreadsheet the document is corrupt and have to be repaired by LibreOffice5. The reason is that there are multiple manifest entries for the same file within the ODF package, as the validator reveals: see http://odf-validator.rhcloud.com I have created a test environment for the Simple API, which copies all dependent files of the sheet aside of the sheet (the table) itself. In addition I have fixed in the test scenario already a minor bug in the Simple API, where attributes without namespaces (an issue of the original document) can not be created - an additional fix for this side problem will be in ODFDOM. The complete fix likely only affects ODFDOM API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ODFTOOLKIT-300) Memory Leak in ODF Simple API
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094330#comment-15094330
]
Svante Schubert commented on ODFTOOLKIT-300:
I translated your entry with Google Translate from Portuguese to English:
--
Well the fastest solution to this would be if the developer created a
clearRepository method in SelectionManager class, leaving the same public in
this way:
clase Selection (package br.gov.serpro.requer.core.odf), public static class
subclass SelectionManager (leave it as public)
Method:
public static void clearRepository ()
{Repository.clear (); }
To resolve this issue, we import all of the following classes in our project:
CellSelection
FieldSelection
GerarAcordao2
ImageSelection
LoadObjFromOdt
Navigation
ParagraphSelection
SaveObjToOdt
Selection
TableSelection
TextDocumentSelection
TextNavigation
TextSelection
Changing only the Selection class, subclass SelectionManager:
public static class SelectionManager {// let the public
..
// create this method
public static void clearRepository ()
{Repository.clear (); }
..
Then in your code just call this:
TextNavigation search = new TextNavigation (tag, TextDocument);
while (search.hasNext ())
{TextSelection item = (TextSelection) search.nextSelection (); FieldSelection
fieldSelection = new FieldSelection (item); fieldSelection.replaceWith (content
= null content!? ""); }
Selection.SelectionManager.clearRepository ();
> Memory Leak in ODF Simple API
> -
>
> Key: ODFTOOLKIT-300
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-300
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Affects Versions: 0.5-incubating
> Environment: odfdom-java-0.8.7.jar; simple-odf-0.6.6.jar
>Reporter: Mathias Silbermann
>Assignee: Devin Han
> Attachments: MemoryLeak_300.java, TestTextSelection.odt
>
>
> There is a memory leak in the ODF Simple API. I tried both, versions 0.6.6
> and 0.6.5. It appears when running code like the examples on cookbook page
> http://incubator.apache.org/odftoolkit/simple/document/cookbook/Manipulate%20TextSearch.html
> In short, the call TextNavigation.nextSelection() leads to the leak. When you
> look down the method's call stack, you will find that items are added to the
> static variable "repository" of the static inner class
> "Selection.SelectionManager". The added items are never removed from the
> repository. One indication is that the method
> Selection.SelectionManager.unregisterItem() is never called.
> The code works fine if text navigation is done with few documents. But when
> its run on a server thousands of times, it will fill the JVMs memory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
