"Type detection failed" error when connecting to remote LibreOffice via API

[jacobo]

I’ve been modifying one of the API examples to connect to a remote LibreOffice install, in particular this document converter: DocumentConverter.java (revision 428e23f4f7025506e767d895e9b46492a8432aed) - OpenGrok cross reference for /core/odk/examples/java/DocumentHandling/DocumentConverter.java

To connect to a remote LibreOffice, I replace the part of the code that retrieves the desktop service in the example with this:

XComponentContext xcomponentcontext = Bootstrap.createInitialComponentContext(null);

XUnoUrlResolver urlResolver = UnoUrlResolver.create(xcomponentcontext);

Object initialObject = urlResolver.resolve(
    "uno:socket,host=10.0.2.2,port=2002;urp;StarOffice.ServiceManager");

XMultiComponentFactory xOfficeFactory = UnoRuntime.queryInterface(
    XMultiComponentFactory.class, initialObject);

XPropertySet xProperySet = UnoRuntime.queryInterface(
    XPropertySet.class, xOfficeFactory);

Object oDefaultContext = xProperySet.getPropertyValue("DefaultContext");

XComponentContext xOfficeComponentContext = UnoRuntime.queryInterface(
    XComponentContext.class, oDefaultContext);

Object oDesktop = xOfficeFactory.createInstanceWithContext(
    "com.sun.star.frame.Desktop", xOfficeComponentContext);

While I’m running LO like this on that host:

soffice --accept="socket,host=0,port=2002;urp;" --headless --nologo --nodefault --nofirststartwizard

I manage to establish a connection, in the sense that I don’t get a NoConnectException, but it doesn’t actually work; instead, I’m getting “type detection failed”:

com.sun.star.lang.IllegalArgumentException: Unsupported URL <file:////tmp/testdocs/the-infrastructure.pptx>: "type detection failed"
    at com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:158)
    at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:122)
    at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:312)
    at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:281)
    at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:81)
    at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:619)
    at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:145)
    at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:129)
    at jdk.proxy1/jdk.proxy1.$Proxy4.loadComponentFromURL(Unknown Source)
    at DocumentConverter.traverse(DocumentConverter.java:116)
    at DocumentConverter.main(DocumentConverter.java:250)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
    at java.base/java.lang.reflect.Method.invoke(Method.java:580)
    at com.sun.star.lib.loader.Loader.main(Loader.java:132)

I’ve seen this problem before, caused by a partial LibreOffice install, but I don’t think this is the case. If I modify the example to run on the same host as LibreOffice, it runs correctly.

Object initialObject = urlResolver.resolve(
    "uno:socket,host=localhost,port=2002;urp;StarOffice.ServiceManager");

I’ve also tried to explicitly set the “FilterName” property before loading the document, like suggested in other posts, but in that case loadComponentFromURL() silently returns a null object.

What do you think about this, am I misusing the API?

[mikekaganski]

@jacobo

If I modify the example to run on the same host as LibreOffice, it runs correctly

Is file:////tmp/testdocs/the-infrastructure.pptx on the same host as LibreOffice, or on the host where you call it from?

And yes, the URL looks wrong - why are there four /s?

[jacobo]

Exactly, that was the problem! So the file:// urls are supposed to be local to the libreoffice binary, not to the client application using the SDK.

The extra / is wrong, but apparently not the cause of the problem. It comes from the example code, it prepends the file:/// prefix with three slashes to build a URL from a local path, and then it concatenates the path I’ve passed via CLI, which starts with a slash: /tmp/testdocs.

Thanks!

[mikekaganski]

@jacobo

the example code, it prepends the file:/// prefix with three slashes to build a URL from a local path, and then it concatenates the path I’ve passed via CLI

Note that not only the fourth slash is wrong then; file URI is not simply a Unix filename, prepended by file:// - it also needs percent-encoding (e.g., that would handle things like space and # in file paths). My suggestion would be to find a command / library / function to create correct URIs from local filenames.

[jacobo]

That’s right, this was just a test based on code from examples but it’s good to remember to properly encode URLs.

Thanks again!