Bug 86784 - make soffice commandline in javaunohelper Bootstrap.bootstrap() configurable
Summary: make soffice commandline in javaunohelper Bootstrap.bootstrap() configurable
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Katarina Behrens (CIB)
QA Contact:
URL:
Whiteboard: target:5.2.0 target:5.1.0.2 target:5...
Keywords:
Depends on:
Blocks: Commandline
  Show dependency treegraph
 
Reported: 2014-11-27 13:05 UTC by Christoph Lutz
Modified: 2017-03-01 12:30 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Lutz 2014-11-27 13:05:27 UTC
In the javaunohelper (juh.jar) there's some code for convenient bootstrapping the UNO bridge via com.sun.star.comp.helper.Bootstrap.bootstrap(). This will raise up an soffice process with the following command line arguments and create an uno bridge via pipe:

soffice --nologo --nodefault --norestore --nocrashreport --nolockcheck --accept=pipe,name=<sPipeName>;urp;

Some of these parameter were causing serious troubles in a real world use case for the java-UNO-bridge. In this scenario, a UNO tool (in concrete the WollMuxBar, which is part of http://www.wollmux.org) is running in the background to perform particular actions in LibreOffice on users request. Since this tool is usually startet near the users login time, in most cases it is the tool that creates the first (main) soffice process. So soffice is started with the above command line. This works fine from UNO point of view.

BUT: in this scenario, the UNO tool is just an add on for LibreOffice and LibreOffice shall be used in the usual way as a desktop application (I call it first scenario). In contrast let's think about a possible 2nd scenario in which LibreOffice is running headless on a server to perform some document conversion tasks - this not our case here.

It seems, the above (hard coded) command line arguments are targetting the 2nd scenario:

--nologo, --nodefault, --nocrashreport make LO silent

--norestore switches of unnecessary (?) recovery features

--nolockcheck switches of unneccessary (?) file locking features

This is definitely conflicting with a normal LO desktop usage. In particular the file locking and recovery features are still required, even if I run a UNO tool in the background.

For that reason, the Bootstrap.boostrap() mechanism should be made configurable. It is OK, to keep the existing command line switches as default, but it should be possible to switch off --norestore and --nolockcheck (and maybe others) if required.

I suggest to introduce a new method Bootstrap.bootstrap(PropertyValue[] bootstrapDescriptor) that accepts a PropertyValue[] in which the above command line switches can be turned off.
Comment 1 Christoph Lutz 2014-12-03 16:35:02 UTC
added a patch to lo gerrit: https://gerrit.libreoffice.org/#/c/13290/
Comment 2 Stephan Bergmann 2014-12-08 09:16:48 UTC
The intended use case of "Simplified Bootstrap" (C++ cppu::bootstrap, Java com.sun.star.comp.helper.Bootstrap.bootstrap) is indeed the case where the calling process is supposed to have full control over the "background" LO process.  That's the rationale for the current set of command line flags.

An underlying problem is that LO will only run a single instance per UserInstallation (forwarding command lines of subsequently started LO instances to the first instance, immediately shutting the subsequent processes down again), but the nature of some of the command line flags does not work well with that, so their values for the first instance are used "globally" and any values for subsequent instances are ignored.

For the command line flags --nologo, --nodefault, and --nolockcheck (which is /not/ about document file locking) this behaviour is harmless, as they pertain only to LO startup, so it does not matter if they are effectively ignored upon the start of an additional LO instance.

More problematic, if a single LO UserInstallation instance shall be accessed in parallel both programmatically and manually, are the --nocrashreport and --norestore (which appears to also control autosave) flags.

I see four potential solutions, in order of preference:

1  Use different UserInstallation settings for the programmatic and the manual LO usage.  Is this an option for your scenario?

2  Analyse how exactly --nocrashreport and --norestore affect behaviour and redesign that to interact better with programmatic access of LO, ultimately obsoleting those flags.  (Is --nocrashreport of any relevance for your scenario anyway, seeing that it only affects either Windows or non-Windows only with optional --enable-crashdump configure switch?)

3  Do not use the "Simplified Bootstrap" convenience functionality if it does not meet your needs.

4  Reuse the "Simplified Bootstrap" convenience functionality and extend it for your needs.
Comment 3 Christoph Lutz 2014-12-08 11:06:26 UTC
> For the command line flags --nologo, --nodefault, and --nolockcheck (which
> is /not/ about document file locking)

according to the documentation for the --nolockcheck switch you are right. But I remember that there were real file locking issues triggered by some of that switches (possibly as some side effects). Sadly I can't find any tickets describing the problem in detail. I need to ask a LHM-person...

> I see four potential solutions, in order of preference:
> 
> 1  Use different UserInstallation settings for the programmatic and the
> manual LO usage.  Is this an option for your scenario?

I think this is not an option here. WollMuxBar is just an "advanced loader" for visible documents that should be handled in exact the same way as other visible office documents that are not loaded by WollMux. The same user settings should be used in both ways.


> 2  Analyse how exactly --nocrashreport and --norestore affect behaviour and
> redesign that to interact better with programmatic access of LO, ultimately
> obsoleting those flags.  (Is --nocrashreport of any relevance for your
> scenario anyway, seeing that it only affects either Windows or non-Windows
> only with optional --enable-crashdump configure switch?)

I don't know much about --nocrashreport and I don't think that's a critical option here. 

The option --norestore is more interesting, as it seems to be configured different on different systems. See e.g. fdo#81906. So I doubt that this option can be removed sometimes - it is about a feature that can be used in two different ways according to the wishes of the desktop maintainer.

And I still think that --nolockcheck needs to be considered here - please let's wait here for an answer from a LHM person.

> 3  Do not use the "Simplified Bootstrap" convenience functionality if it
> does not meet your needs.

The simplified bootstrap in principle does what we need. It starts office if it is not present. There's currently no other way for that that is supported by juh.jar.

> 4  Reuse the "Simplified Bootstrap" convenience functionality and extend it for your needs.

That's what I want to do. I think you agree that others should be able to benefit from such a solution, too. Don't you? I really think that others could face similar problems. So having this code in a private area in WollMux is not what I would prefer.
Comment 4 Christoph Lutz 2014-12-09 09:11:38 UTC
This issue describes the problems the LHM had with --nolockcheck. Yes, it's an AOO bug, and it was first seen in the old OOo 3.2.1.  

https://issues.apache.org/ooo/show_bug.cgi?id=108936

It's currently not clear, if this issue is (still) there in LibreOffice - I will try to verify this, but I think I need a special infastructure for the tests, first. Not sure when I will find the time to test it.
Comment 5 ulkitz 2014-12-09 19:59:07 UTC
Christoph, could you check whether fdo71005 describes the problem? If so, it should be solved.
Comment 6 Commit Notification 2015-12-18 13:26:13 UTC
Katarina Behrens committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=02002f83f156117cf178532d48abaa9319ee8cb4

tdf#86784: Pass custom options to Java bootstrap

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 7 Commit Notification 2015-12-21 14:21:22 UTC
Katarina Behrens committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8cb4fe7ff4ea5227ebe416617c16c9abfa437ff0&h=libreoffice-5-1

tdf#86784: Pass custom options to Java bootstrap

It will be available in 5.1.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2015-12-21 17:30:00 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=77a202cbbf3735a6007ceb09f96f5e9258ef6df2

related tdf#86784: new API got backported to 5.1

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2015-12-22 01:29:01 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c40c24e9ce333924952d6b1c643a4cc9a3f859af&h=libreoffice-5-1

related tdf#86784: fix since string for new API

It will be available in 5.1.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2015-12-22 14:42:04 UTC
Katarina Behrens committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb6939cc689a44c1039508935312df98e12f4081&h=libreoffice-5-0

tdf#86784: Pass custom options to Java bootstrap

It will be available in 5.0.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Xisco Faulí 2016-09-15 22:27:58 UTC
Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Comment 12 Katarina Behrens (CIB) 2017-03-01 12:30:39 UTC
Nobody complained so far. Let's set it to fixed