Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||getElementNames error for AutoTextGroup if file name does not match block-list:list-name|
|Product:||App Dev||Reporter:||joelgr77 <jr>|
|Component:||api||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Version:||3.3.0 or older (OOo)|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description joelgr77 2004-02-26 17:05:34 UTC
When using the Java API to list AutoText entries, the following stack trace is produced if there is an AutoText file in the AutoText path whose file name does not match the XML entry block-list:list-name This can be demonstrated using the example code TextDocuments.java by renaming an AutoText file. Writer will open the file and display the AutoText entries while attempting to list entries via the API generates the following: GetReference text field inserted for ReferenceMark : TableHeader com.sun.star.uno.RuntimeException: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at com.sun.star.lib.uno.protocols.urp.Unmarshal.readThrowable (Unmarshal.java:315) at com.sun.star.lib.uno.protocols.urp.Unmarshal.readAny (Unmarshal.java:157) at com.sun.star.lib.uno.protocols.urp.Unmarshal.readObject (Unmarshal.java:404) at com.sun.star.lib.uno.protocols.urp.urp.readReply(urp.java:192) at com.sun.star.lib.uno.protocols.urp.urp.readMessage(urp.java:308) at com.sun.star.lib.uno.protocols.urp.urp.readMessage(urp.java:607) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.in voke(java_remote_bridge.java:182) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.ru n(java_remote_bridge.java:173) Renameing the file, or editing the XML entry will fix the problem.
Comment 1 joelgr77 2004-02-26 19:44:40 UTC
After further testing I find that using the "Edit Autotext" in a writer seems to fix something so that the API can access the autotext entries. Joel
Comment 2 stephan.wunderlich 2004-02-27 11:36:33 UTC
SW->Joel: I could reproduce this with my OOo1.1 only if I renamed the Autotext-file while the office ran and then executed the mentioned sample. If I changed the filename while the office wasn't up all works fine. AFAIK the list auf available autotexts is gained when the someone tries to use autotexts for the first time, so lets say you had a.bau b.bau c.bau as the office started and since they have been used sometime, this is the list of files that will be parsed. If you now rename b.bau to b_2.bau, opening the file b.bau will fail what raises a RuntimeException. For me this looks like the expected behaviour and not like a bug.
Comment 3 joelgr77 2004-02-27 14:00:50 UTC
I would expect the API to behave the same as the application, or at least provide a method to refresh the list. Clearly writer is refreshing it's list of AutoText entries as I do not get an error message when I open the AutoText entries via writer.
Comment 4 joelgr77 2004-02-27 16:36:33 UTC
In unoatxt.cxx there is the comment // TODO: think about if we should pass "true" here // The difference would be that when the next modification is made to this instance here, then // we would be forced to open the document again, instead of working on our current copy. // This means that we would reflect any changes which were done to the AutoText by foreign instances // in the meantime Please consider at least adding a method to force a reload/revalidate of the cache. Thanks
Comment 5 stephan.wunderlich 2004-03-01 09:51:32 UTC
SW->Joel: mmmh, the cited comment is from the SwXAutoTextEntry::XAutoTextEntry::applyTo() and the issue you stated first was related to SwXAutoTextGroup::XNameAccess::getElementNames() and SwXAutoTextContainer::XNameAccess::getElementNames() respectively. So I don't see the relation between this addition and the original issue :-) The problem I have with this issue is that I don't see a benefit in adding an additional Interface to the two containers to catch the rare case that the files on disc change their names while the office runs with refreshing the container instead of throwing a RuntimeException. Can you describe a scenario where one will stumble over this while using the API or is it just a 'hypothetic' issue ?
Comment 6 joelgr77 2004-03-01 15:09:29 UTC
The heart of the issue is when there is a mis-match between the cache and the backing-store, which should be used. One can 1) ignore the mis-match; 2) reload the cache from the store; 3) throw an error. I pointed to the code section to show that one of your developers thought that rebuilding the cache might be the right thing to do, and that I wasn't completely crazy to suggest the some thing. I wouldn't mind throwing an exception if it had actually told me what the problems was. Throwing a "something went wrong someplace" exception is not very helpful. I am working on an Java application that uses writer as part of a larger document generation/management system. Part of the system includes an AutoText group that is available only when the doc management system is running. The AutoText file is stored in the database and fetched to the user's work area when a document (also stored in a database) is fetched for editing. Since the AutoText file can be edited and updated at any time by an authorized user I need to be able to refresh the AutoText on every document load. And while the AutoText entries are (in my opion) correctly refreshed for the user using writer, I cannot access the entries from the API. I had hoped to use document fragments in AutoText to populate the document based on values in the database. For example, for a document of type 'A' for a customer of type 'B' we need paragraphs 'Foo', 'Bar', and table 'Blah'. One advantage of using AutoText is that the user can also insert a 'Foo' paragraph if it is needed.
Comment 7 stephan.wunderlich 2004-03-02 09:50:47 UTC
SW->TL: I suppose the 'autoupdate' on each container access has been avoided because of performance reason and since it is most likely not needed during 'normal' access of these containers, I'd say adding the interfrace css.util.XRefreshable optional to these containers could make the 'ui-like' behaviour available for API-users too.
Comment 8 stephan.wunderlich 2004-03-02 09:51:29 UTC
SW: changed state
Comment 9 ace_dent 2007-01-31 23:20:30 UTC
Should this Issue be 'New' and resolved as WONTFIX?...
Comment 10 ace_dent 2008-05-28 23:13:58 UTC
This Issue has been marked as 'Invalid' and not updated in 1yr+ ... any update on where this should be going? Many thanks, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~
Comment 11 Mechtilde 2008-11-07 19:57:50 UTC