Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cuba.reporting.openoffice.path seems to be ignored in my Windows. #124

Open
ams-tschoening opened this issue Feb 5, 2020 · 1 comment
Open
Assignees

Comments

@ams-tschoening
Copy link

ams-tschoening commented Feb 5, 2020

Environment

  • YARG version: current master (2.2.5)
  • Client type: Desktop
  • Operating system: Windows 10 1909

Description of the bug or enhancement

I've simply cloned current master of the repo and ran gradlew build on the shell, which results in errors like the following:

C:\Users\tschoening\Downloads\yarg\core>gradlew build --stacktrace
Starting a Gradle Daemon (subsequent builds will be faster)

> Task :yarg:test

smoketest.DocSpecificTest > testTableOdt FAILED
    java.lang.RuntimeException at DocSpecificTest.java:58
        Caused by: com.haulmont.yarg.exception.OpenOfficeException
            Caused by: com.haulmont.yarg.formatters.impl.doc.connector.BootstrapException
                Caused by: com.haulmont.yarg.formatters.impl.doc.connector.BootstrapException
<=====--------> 40% EXECUTING [1m 2s]
> :yarg:test > 73 tests completed, 1 failed, 1 skipped
> :yarg:test > Executing test smoketest.DocSpecificTest
Batchvorgang abbrechen (J/N)? j

C:\Users\tschoening\Downloads\yarg\core>

Looking at the XML files created for test results by Gradle, the root cause always is the following:

Caused by: com.haulmont.yarg.formatters.impl.doc.connector.BootstrapException: no office executable found!
	at com.haulmont.yarg.formatters.impl.doc.connector.OOServer.start(OOServer.java:103)
	at com.haulmont.yarg.formatters.impl.doc.connector.BootstrapConnector.connect(BootstrapConnector.java:103)
	... 7 more

At first that made sense, because the path to LibreOffice is configured in reporting.properties and simply doesn't fit my setup:

cuba.reporting.openoffice.path=/usr/lib/libreoffice/program

The problem is that after changing that path to where I really have my LibreOffice installed, things still fail:

cuba.reporting.openoffice.path=C:/Program Files/LibreOffice/program

As can be seen by the path, I'm using a 64 Bit version of LO and installed it in the platform default directory. But nevertheless, the tests keep failing. So I debugged things with Process Monitor and recognized that my configured path seems to be ignored entirely. The above path NEVER shows up in the logs, only the following does ALWAYS:

C:\Program Files (x86)\LibreOffice\program
14:08:23,4883739	java.exe	9452	CreateFile	C:\Program Files (x86)\LibreOffice\program	PATH NOT FOUND	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a

Note the suffix (x86), so for some reason YARG is looking for a 32 Bit version of LO. That makes me especially wondering because Gradle is executed using a 64 Bit Java es well and I don't know where in the process of trying to load LibreOffice anything 32 Bit-related could come into play.

Additionally, that path doesn't seem to be configured anywhere. I've tried all other combinations of paths in the config file I can think of: Forward vs. backslashes, file-URLs, relative paths etc. and additionally added nonsense directories like murks in the path, just to have something unique to search for. But none of my paths or murks have been found in the logs of ProcMon, so YARG simply doesn't seem to do anything with that. I always only find the path above, so it seems to be some kind of fallback, but couldn't find where it comes from.

So, do you have any example of how a Windows-path to LibreOffice needs to look like?

Regarding your code, you are supporting loading LO on Windows in general, as you explicitly use a binary called soffice.exe in those cases.

Where does that fallback come from?

I've already looked at who tries to load LO at all, but couldn't find that path there as well:

https://github.com/LibreOffice/core/blob/master/jurt/com/sun/star/lib/util/NativeLibraryLoader.java

Do I need to do more than to change the path in reporting.properties?

I already verified that my changed file is really copied as resource for the tests by Gradle, that the changed file is read during running the tests etc. All that can bee seen in ProcMon, I only can't see usage of any of my configured paths.

Thanks for your help!

@ams-tschoening
Copy link
Author

Finally found the problem, the tests really ignore reporting.properties:

protected String openOfficePath = System.getenv("YARG_OPEN_OFFICE_PATH");
protected String fontsDirectory = System.getenv("YARG_FONTS_DIRECTORY");

public AbstractFormatSpecificTest() {
    if (StringUtils.isBlank(openOfficePath)) {
        openOfficePath = "C:/Program Files (x86)/LibreOffice/program";
    }

    if (StringUtils.isBlank(fontsDirectory)) {
        fontsDirectory = "C:/Windows/Fonts";
    }
}

Is that really necessary if reporting.properties seems to be available to the test? Especially with widespread usage of 64 Bit-software, I suggest at least adding another fallback for the 64 Bit-install dir of LibreOffice if the 32 Bit doesn't exist or something like that.

The following makes the test succeed now:

C:\Users\tschoening\Downloads\yarg\core>set YARG_OPEN_OFFICE_PATH=C:/Program Files/LibreOffice/program
C:\Users\tschoening\Downloads\yarg\core>gradlew build --stacktrace

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants