Apache OpenOffice (AOO) Bugzilla – Issue 44081
Java Macros attached via the XStorage API are lost when saving the document
Last modified: 2013-02-24 21:06:30 UTC
We deploy "Java macros" for the Scripting Framework by using the XStorage API to embed them directly from the development tool into an open OpenOffice Document via UNO. (More exactly, they are opened in an OpenOfficeBean) But they are then lost after saving the document. In the open OpenOffice instance, they are present after deployment - you can attach keyboard shortcuts or new buttons to them. At this time, they are even present in the document file (XStorage access changes file on filesystem !) (grabbed a copy and opened with Winzip - see attached file hust_withmacros.odt). Saving the document (Ctrl-S or Save button) changes the situation again: They are neither in the running Office instance, nor in the just saved file. (See attached file hust_aftersave.odt) Perhaps intersting side effect: Putting a java macro by accessing the document as zip file, the effect is different: The macros are present when opening the file in OpenOffice and by saving the document again, they are still there. But as soon as they are touched with XStorage (deployed using zip, opened in OpenOffice to re-delpoy over XStorage) saving the document again makes them disappear. Sorry for no java code snippets - but it is just straight-forward plain file access over XStorage, thereby creating the directory structure necessary for the ScriptingFramework
Created attachment 23345 [details] document after deployment via XStorage, before hitting "Save"
Created attachment 23346 [details] document after hitting "Save" - all macros gone
Also observed in 1.9.65 and StarOffice 8 Beta
as far as I know XStorage is your area
First of all the root storage of the document should be commited only by the document. Commiting of the root document storage from outside should never be done. The "Script" substorage is removed because it is not treated as a part of the document, since it has no mediatype, usually this storage has mediatype "application/binary". ( To avoid removing of any document extension during document storing, the extension must be placed in a substorage of the root storage and this substorage must have a "unique" mediatype, means that is should not be handled by the office itself ).
This issue was no bug in the XStorage API, but in the handling by our code. The "solution" is by no means semantically intuitive and definitely has to be documented.
The Issue you raised has been marked as 'Resolved' and not updated within the last 1 year+. I am therefore setting this issue to 'Verified' as the first step towards Closing it. If you feel this is incorrect, please re-open the issue and add any comments. Many thanks, Andrew Cleaning-up and Closing old Issues ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
As per previous posting: Verified -> Closed. A Closed Issue is a Happy Issue (TM). Regards, Andrew