Kablink Vibe (it used to be named Kablink Teaming - see http://kablink.org/teaming) uses OpenOffice or LibreOffice for document conversions. It uses it these convert various document formats to XML (for search word extraction) or to HTML (for rendering in a browser.) With the latest versions of LibreOffce (i.e., 3.4.x), the conversions have stopped working with the following exception: 2011-12-01 15:49:03,809 ERROR [http-8080-4] [org.kablink.teaming.module.folder.impl.DefaultFolderCoreProcessor] - AbstractBinderProcessor.buildIndexDocumentFromFile( EXCEPTION:1 ): com.sun.star.lang.DisposedException: java.io.IOException: com.sun.star.io.IOException: EOF reached - socket,host=localhost,port=8100,localHost=localhost,localPort=41133,peerHost=localhost,peerPort=8100 at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.invoke(java_remote_bridge.java:237) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.run(java_remote_bridge.java:144) If we revert of LibreOffice 3.3.4 (or OpenOffice 3.3.0), the exact same code works without failure. It's only with versions 3.4.x of LibreOffice that the failures started happening. At the lowest level, Kablink Vibe uses the storeToURL() method off an XStorable object to perform the conversion. In the failure case, the code doesn't reach the point of that call as it appears to die in Vibe's call to the resolve() method off an XUnoUrlResolver object. The code being executed up to the point of failure are: /* Bootstraps a component context with the jurt base components * registered. Component context to be granted to a component for running. * Arbitrary values can be retrieved from the context. */ xcomponentcontext = Bootstrap.createInitialComponentContext(null); /* Gets the service manager instance to be used (or null). This method has * been added for convenience, because the service manager is a often used object. */ xmulticomponentfactory = xcomponentcontext.getServiceManager(); /* Creates an instance of the component UnoUrlResolver which supports the services specified by the factory. */ objectUrlResolver = xmulticomponentfactory.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", xcomponentcontext); // Create a new url resolver xurlresolver = (XUnoUrlResolver)UnoRuntime.queryInterface(XUnoUrlResolver.class, objectUrlResolver); // Resolves an object that is specified as follow: // uno:<connection description>;<protocol description>;<initial object name> objectInitial = xurlresolver.resolve("uno:socket,host=" + _host + ",port=" + _port + ";urp;StarOffice.ServiceManager"); Although Kablink Vibe administrators have a workaround (downgrade to LibreOffice 3.3.4 or OpenOffice 3.3.0), it's unsatisfactory for openSuSE users in that the standard LibreOffice version bundled with openSuSE is version 3.4.2, which does not work. Note that I've tried this using version 3.4.4rc2 as downloaded from www.libreoffice.org with the same result. If I download version 3.3.4 and use that, everything works. Again, using the EXACT SAME installed version of Kablink Vibe, the conversions work without error with LibreOffice 3.3.4 and OpenOffice 3.3.0. It's only since the update for LibreOffice 3.4.x that the failures started. Note that Kablink Vibe is an open source project and the source can be freely downloaded. The source modules within that project where the failures occur include TextOpenOfficeConverter.java and HtmlOpenOfficeConverter.java.
i have exact the same problem with version 3.4.2 while 3.3.4 works. in my program the Exception is raised at a call to bridge = xBridgeFactory.createBridge("", "urp", "socket,host=127.0.0.1,port=9000", null);
(In reply to comment #1) > i have exact the same problem with version 3.4.2 while 3.3.4 works. > in my program the Exception is raised at a call to > bridge = xBridgeFactory.createBridge("", "urp", > "socket,host=127.0.0.1,port=9000", null); CORRECTION: The bridge is created, but the next call fails; bridge.getInstance("StarOffice.ServiceManager");
after replacing the necessary jar-files with those from 3.4.2 everything works fine ;)
Thanks for bugreport Please, verify if in last version of LibreOffice still reproducible
In response to comment#4: Using LibreOffice 3.5.2, the same exception I originally reported continues to occur. With LibreOffice 3.5.2, the exception I'm getting is: com.sun.star.lang.DisposedException: java.io.IOException: com.sun.star.io.IOException: EOF reached - socket,host=localhost,port=8100,localHost=localhost,localPort=58374,peerHost=localhost,peerPort=8100 at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.invoke(java_remote_bridge.java:237) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.run(java_remote_bridge.java:144) ...and on and on... This exception occurs with each and every attempt to convert a document using LibreOffice 3.5.2. Note that version 3.3.* and earlier of LibreOffice continue working without error.
Thanks for additional testing
kablink.org appears to be unreachable atm. Can you produce a stripped down scenario that exhibits the problem? (How do you start LibreOffice? Could it be that you explicitly start soffice.bin instead of soffice?)
(In reply to comment #7) > kablink.org appears to be unreachable atm. Can you produce a stripped down > scenario that exhibits the problem? (How do you start LibreOffice? Could it > be that you explicitly start soffice.bin instead of soffice?) We have the same problem and we start the office service like its recommended in the kablink vibe onprem documentation: soffice "-accept=socket,host=localhost,port=8100;urp; StarOffice.ServiceManager" -nologo -headless
kablink.org appears to be available again, but I can still not make much of what I find there. What I would of course prefer is a stripped down scenario (a Java file and a makefile, say) that demonstrates the problem. What would be second best would be a pointer to the kablink source code that does the communication with LO.
The source for the lastest release version of Kablink Vibe can be downloaded from SourceForge. See: http://kablink.svn.sourceforge.net/viewvc/kablink/branches/granite/ The LibreOffice/OpenOffice converters are invoked to convert to HTML in HtmlOpenOfficeConverter.java and the text word extraction conversion is done in TextOpenOfficeConverter.java. Both of these exhibit the problem described by this bug.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=edaf3e8cd146f5dadb73f1aebdf990f8a2656bc3 fdo#43433: Binary URP works gracefully with old Java URP
Kablink includes very old URE jars (jurt.jar, ridl.jar, etc.), from OOo 2.0 according to <http://kablink.svn.sourceforge.net/viewvc/kablink/branches/granite/ssf/lib/versions.txt?revision=17338&view=markup>. The Java URP implementation in old OOo had a bug that it does not support protocol properties (<http://wiki.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol#Protocol_Property_Messages>), only fixed in OOo 2.2 (<https://issues.apache.org/ooo/show_bug.cgi?id=35277> "Java URP: Support Manipulation of Protocol Properties"). The new binary URP implementation (post OOo 3.3) did not gracefully handle a remote end that violates the URP specification in that way, and instead terminated the connection.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d6a1b16de3df06a798d1e728219090810e6c1ebe&g=libreoffice-3-5 fdo#43433: Binary URP works gracefully with old Java URP It will be available in LibreOffice 3.5.7.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d58a927f4a66d2df9872fbe0a609b67f90f85147&g=libreoffice-3-6 fdo#43433: Binary URP works gracefully with old Java URP It will be available in LibreOffice 3.6.2.
The problem seems to exist again in LibreOffice 4.0.3 Connection works fine with LibreOffice 3.6, but fails with 4.0 Other users seem to run into this problem after upgrading to 4.0: http://ask.libreoffice.org/en/question/12667/libreoffice-4-uno-refuses-connection-to-running/ http://fakturama.sebulli.com/phorum/read.php?1,2219,2221,quote=1 Possibly the patch not merged to the new release?
Disregard my previous comment! It turns out we hadn't added the correct jars bundled with LibreOffice 4.0 to our classpath. Fixing this fixes the issues.
Tested with LibreOffice 4.0.4 and same problem again (but not in all cases, sometimes the PDF convert is ok sometimes I still get the exception IOException: EOF reached)
We use LibreOffice embedded within an Eclipse RCP application. With LibreOffice 4.1.3 and 4.0.5 the following exception is thrown on Windows 8 64bit and with LibreOffice 4.1.2 on ubuntu 13.10: java.io.IOException: com.sun.star.io.IOException: EOF reached - socket,host=127.0.0.1,port=8100,tcpNoDelay=1,localHost=127.0.0.1,localPort=53672,peerHost=127.0.0.1,peerPort=8100 at com.sun.star.lib.uno.bridges.java_remote.XConnectionInputStream_Adapter.read(XConnectionInputStream_Adapter.java:50) at java.io.DataInputStream.readInt(DataInputStream.java:387) at com.sun.star.lib.uno.protocols.urp.urp.readBlock(urp.java:350) at com.sun.star.lib.uno.protocols.urp.urp.readMessage(urp.java:87) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.run(java_remote_bridge.java:96) The code which triggers the exception seems to be: XFrame xFrame = (XFrame) UnoRuntime.queryInterface(XFrame.class, object); xFrame.initialize(xWindow); xFrame.setName("AnOfficeFrame"); // raises an exception on LibreOffice 4.x With older 3.x versions, e.g. LibreOffice 3.6.7, the same code runs without failure!
(In reply to comment #18) > The code which triggers the exception seems to be: > XFrame xFrame = (XFrame) UnoRuntime.queryInterface(XFrame.class, object); > xFrame.initialize(xWindow); > xFrame.setName("AnOfficeFrame"); // raises an exception on LibreOffice 4.x Juergen, your problem looks rather unrelated to this issue. Please file a new issue, and include a minimal yet complete reproduction recipe.
(In reply to comment #17) > Tested with LibreOffice 4.0.4 and same problem again (but not in all cases, > sometimes the PDF convert is ok sometimes I still get the exception > IOException: EOF reached) David, do you still experience that problem with recent versions of LibreOffice? If conversion only fails sometimes, it should not be due to the problem originally discussed and fixed in this issue. There can be other problems that exhibit the same symptom of an "EOF reached" exception, though. If the problem still persists for you, are there specific PDF files that consistently fail, or does it sometimes fail and sometimes work for any given PDF file? If the former, can you attach such a consistently failing PDF file here?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO