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.
added a patch to lo gerrit: https://gerrit.libreoffice.org/#/c/13290/
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.
> 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.
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.
Christoph, could you check whether fdo71005 describes the problem? If so, it should be solved.
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.
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.
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.
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.
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.
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
Nobody complained so far. Let's set it to fixed