Bug 31229 - The bootstrap function of the LibO API functionality doesn't work
Summary: The bootstrap function of the LibO API functionality doesn't work
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-30 02:31 UTC by Giuseppe Castagno (aka beppec56)
Modified: 2011-12-23 15:38 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Change symlink in packaging and adapt ../program/soffice start script. (1.53 KB, patch)
2010-10-30 02:35 UTC, Giuseppe Castagno (aka beppec56)
Details
Change installation path search in Java (1.13 KB, patch)
2010-10-30 02:36 UTC, Giuseppe Castagno (aka beppec56)
Details
Change installation path search in testtool (3.64 KB, patch)
2010-10-30 02:37 UTC, Giuseppe Castagno (aka beppec56)
Details
Change installation path search in C/C++ (922 bytes, patch)
2010-10-30 02:39 UTC, Giuseppe Castagno (aka beppec56)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Giuseppe Castagno (aka beppec56) 2010-10-30 02:31:27 UTC
These two features described on OOo DevGuide:
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components#Finding_a_UNO_Installation
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/C%2B%2B/Transparent_Use_of_Office_UNO_Components#Finding_a_UNO_Installation

At the moment for LibO don't work as described.

Only the possibility with the added parameters will work; that is,for Java binding you need to use:

java -Dcom.sun.star.lib.loader.unopath=/opt/libreoffice/program -jar SimpleBootstrap_java.jar

and for C++ binding you need to use these two steps:

setenv UNO_PATH /opt/libreoffice/program
./SimpleBootstrap_cpp

whereas the automatic search for an installed LibO installation won't work in both cases, e.g for Java:

java -jar SimpleBootstrap_java.jar

and for C++

./SimpleBootstrap_cpp

Both will connect to OOo instead.
This is true in the case the user uses the helper classes available in LibO SDK.
For details how all this is supposed to work, the same pages of the OOo DevGuide recalled above are explanatory.

The Java and C++ bindings have two functions that use the symlink /usr/bin/soffice in order to reach the actual LibO installation.
So /usr/bin/libreoffice should be symlinked to /opt/libreoffice/program/soffice, or more generally to <install dir>/program/soffice

The soffice and soffice.bin inside ../program must stay named as now, because they can be used as target for autostart of LibO.

There is mail already exchanged on the topic, in which I'm afraid I didn't explain the problem in details:

http://lists.freedesktop.org/archives/libreoffice/2010-October/000416.html
http://lists.freedesktop.org/archives/libreoffice/2010-October/001031.html

Some matter may still be open; ATM I don't know the way python and CLI bindings work; I'm not sure they require the same changes.

A quick and easy way to see the behavior described here is to try with testtool in universal LibO:

To reproduce (test carried out with a build from a pull -r done on Oct,20th around 2 pm):
1) install universal LibO, it will show up in /opt/libreoffice.
2) following the steps here: http://wiki.documentfoundation.org/Qa/testing/Using_Testtool
prepare the testtool environment and start the test as instructed
3) Oracle OOo is started instead of LibO.

Solutions to the symlink issue: I see two possible:

1) apply the patches I will attach, so the original behavior is restored;

2) leave the situation as it is, but documenting somewhere in the LibO DevGuide how the features above are working (e.g. the need to always specify
the path on the start line); and if testtool will be needed for testing update testtool code accordingly.

A test case can be built using Java, as an example, there is a Java program here:

http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/FirstSteps/First_Contact

I modified and adapted it to check this issue, but I didn't attach it here because I'm not sure of the license issues: the PDL for documentation,
does it fit the guidelines/bylaws here?
Comment 1 Giuseppe Castagno (aka beppec56) 2010-10-30 02:35:25 UTC
Created attachment 39893 [details]
Change symlink in packaging and adapt ../program/soffice start script.
Comment 2 Giuseppe Castagno (aka beppec56) 2010-10-30 02:36:23 UTC
Created attachment 39894 [details]
Change installation path search in Java
Comment 3 Giuseppe Castagno (aka beppec56) 2010-10-30 02:37:25 UTC
Created attachment 39895 [details]
Change installation path search in testtool
Comment 4 Giuseppe Castagno (aka beppec56) 2010-10-30 02:39:31 UTC
Created attachment 39896 [details]
Change installation path search in C/C++
Comment 5 Caolán McNamara 2010-11-01 07:55:14 UTC
Surely the easiest thing to do is to add a /usr/bin/soffice that points to the right place no ?
Comment 6 Giuseppe Castagno (aka beppec56) 2010-11-01 08:29:59 UTC
That would work, but only if OOo is not installed on the same machine.

In this case the OOo symlink /usr/bin/soffice will 'confuse' LibO tooling, pointing it to OOo environment instead.
Comment 9 Petr Mladek 2010-11-12 11:01:26 UTC
Giuseppe, could we close this bug as fixed or do we need more changes?
Comment 10 Giuseppe Castagno (aka beppec56) 2010-11-13 00:57:16 UTC
(In reply to comment #9)
> Giuseppe, could we close this bug as fixed or do we need more changes?

Petr, you may close it.
This morning I was finally able to test it and appears fixed on master.

I wasn't able to check it before.
Comment 11 Giuseppe Castagno (aka beppec56) 2010-11-13 01:01:05 UTC
Closed it myself, I noted that Petr is not on cc list.
Comment 12 sophie 2011-01-13 06:48:46 UTC
Closing - Sophie
Comment 13 Björn Michaelsen 2011-12-22 05:52:57 UTC
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.