Issue 25914 - getElementNames error for AutoTextGroup if file name does not match block-list:list-name
Summary: getElementNames error for AutoTextGroup if file name does not match block-lis...
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2004-02-26 17:05 UTC by joelgr77
Modified: 2013-02-24 21:07 UTC (History)
2 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
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 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 
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
        at java.lang.reflect.Constructor.newInstance(

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.

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 
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 

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,

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