Issue 99257 - test scripts for cli_uno types failing, shared extension problem
Summary: test scripts for cli_uno types failing, shared extension problem
Alias: None
Product: App Dev
Classification: Unclassified
Component: scripting (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All Windows, all
: P3 Trivial
Target Milestone: ---
Assignee: Olaf Felka
QA Contact: Unknown
: 93914 (view as issue list)
Depends on:
Reported: 2009-02-16 10:16 UTC by Olaf Felka
Modified: 2017-05-20 09:32 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Olaf Felka 2009-02-16 10:16:41 UTC
- running the test.exe scripts for the cli_uno types
- tests won't complete with an exception
Comment 1 Olaf Felka 2009-02-18 10:47:28 UTC
setting new target 
Comment 2 Olaf Felka 2009-02-18 10:50:33 UTC
typo in summary
Comment 3 joachim.lingner 2009-02-18 13:26:43 UTC
The test program starts OOo serveral times, opens a spreadsheet and fills in
some data. This causes a call into the extension manager. When it is
initialized, then it copies a common.rdb to a common_.rdb or vici versa. These
files are in 

The copying is done by the system function CopyFile which fails. GetLastError()
returns 1224 which represents this error: ERROR_USER_MAPPED_FILE,  The requested
operation cannot be performed on a file with a user-mapped section open. 

Comment 4 joachim.lingner 2009-02-18 15:35:49 UTC
The common.rdb or common_.rdb are locked by the client program (runtests). When
the client starts then it creates the cli-uno bridge in its process, which
bootstraps UNO using the libraries from the office installation. Bootstrapping
UNO includes setting up the service manager, which causes all services rdb
files, such as common.rdb, to be opened. The file will then remain opened as
long as the client runs. When the client restarts OOo then OOo cannot overwrite
the common.rdb, which is still opened by the client. 

This problem has become visible, because OOo is now bundled with a couple of
extensions. Opening a calc document will now lead to a call into the service
The bug does only affect the cli-uno bridge, AFAIK.

The work around is to use the quickstarter of OOo.

Possible fixes are:

1. Allow adding / removing services of the loaded rdb files

2. Invent  another mechanism of how the extension services  are registered

3. Write a real cli-uno remote bridge. The current bridge is actually an
inprocess bridge, which was intended for using cli-uno components.

All three solutions are time consuming and to risky for 3.1. I therefore suggest
to retarget this issues as long as OF can verify that the workaround works.

Comment 5 joachim.lingner 2009-02-18 16:03:52 UTC
See also issue 93914.
Comment 6 joachim.lingner 2009-02-19 12:24:28 UTC
Another workaround is that the user does not have write access to OpenOffice
3/share folder.
Comment 7 Olaf Felka 2009-02-23 12:20:28 UTC
Not happy with target 3.2 but: To risky to fix.
Comment 8 Olaf Felka 2009-02-23 12:21:25 UTC
Removing the blocked issue id.
Comment 9 joachim.lingner 2009-02-27 10:18:11 UTC
I thought that I caused the problem by allowing to install shared extension in
OOo 2.3 but this is not the case. The copying of the common.rdb also happens in
OOo 2 final (m124). What was different then was that the extension manager
dialog checked if the office is runnging. If this was the case then it did not
allow to install/remove shared extensions. 

That the original problem has been existing for ages but only became obvious by
the now bundled writer2latex extension.

@of: This is actually no regression. Consider deleting the key word.

Sun internal issue 159202 is also caused by this.

The only useful fix is to prevent this copying of the rdb. This would either
require read and writable registry files, or the shared extensions must be
installed before UNO is bootstrapped in OOo. Both solutions would cost quite
some time to implement.
Comment 10 joachim.lingner 2009-03-20 16:53:35 UTC
Maybe there is a simple solution: Only copy the common.rdb (and change the
unorc, etc) whenever a shared extension is being installed. That is what now is
done every time the extension manager is initialized will then only be carried
out on demand. Because we say that no other instance of OOo may be running when
installing shared extensions, we cannot run into problems. Of course
boostrapping and UNO environment which is done when using a cli client program
must also be regarded as 'running another instance'.
Comment 11 joachim.lingner 2009-07-22 09:38:43 UTC
*** Issue 93914 has been marked as a duplicate of this issue. ***
Comment 12 joachim.lingner 2009-08-31 10:34:28 UTC
target 3.3
Comment 13 joachim.lingner 2009-12-03 15:14:09 UTC
@QA: Please test extensively adding and removing extension. One should add some
extensions, restart OOo and check if the extensions are still there and working.
Use extensions which contain c++ and Java services.

Further testing can be done by running the test case for Sun internal issue
159202 (Sun internal) and running the cli test program ( OF knows about this).
Then install the sun presentation minimizer extension or any other extension
which uses help files. Running the test with a master office will fail with an
exception (start the test from a console, to see the exception).
Comment 14 joachim.lingner 2010-01-13 16:03:39 UTC
Comment 15 joerg.skottke 2010-01-29 11:44:00 UTC
As i'm not familiar with this stuff, i change owner.#

@HI: You submitted and verified a similar issue, please take over.
Comment 16 Olaf Felka 2010-02-18 11:58:12 UTC
The fix looks good for me in cws jl145.
Comment 17 Olaf Felka 2010-02-18 11:58:43 UTC