Apache OpenOffice (AOO) Bugzilla – Issue 88687
C++/Java Simple Bootstrap broken
Last modified: 2013-02-24 21:08:33 UTC
The C++ and Java "Simple Bootstrap" mechanisms (<http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/C%2B%2B/Transparent_Use_of_Office_UNO_Components> and <http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components>) no longer work, see <http://udk.openoffice.org/servlets/ReadMsg?list=dev&msgNo=4034>.
.
Added program/unoinfo in the Brand layer. With argument "c++" it prints to stdout an absolute pathname where the URE libraries can be found (in UTF-16LE on Windows). With argument "java" it prints to stdout a byte ASCII "0" or "1" followed by a string (of bytes in "0" mode or UTF-16LE in "1" mode) that is a sequence of zero or more null-character separated absolute pathnames that need to be on the class path. Adapted both C++ and Java "Simple Bootstrap" mechanisms (see above) to obtain the necessary information via the new unoinfo. The net result is that newly built Simple Bootstrap applications should work against old and new OOo installations, but old Simple Bootstrap applications will not work against new OOo installations. For testing, you can use examples/DevelopersGuide/ProfUNO/SimpleBootstrap_cpp|java from the SDK. (While the SDK for OOo 3.0 does not yet work, you can use an older SDK and modify the built Simple Bootstrap applications as follows: For SimpleBootstrap_cpp replace the generated SimpleBootstrap_cpp[.exe] with odk/<platform>/bin/unoapploader[.exe]. For SimpleBootstrap_Java add/replace com/sun/star/lib/loader/Loader.class and com/sun/star/lib/loader/Loader$Drain.class from odk/<platform>/class in the generated SimpleBootstrap_java.jar.
@jsc: please verify
jsc: verified on Solaris, Linux and Windows. On Mac OSX there is still a problem but there it has never been worked before. Follow up issue i89507 to address the Mac OSX problem separately.
*** Issue 89770 has been marked as a duplicate of this issue. ***
This issue is marked fixed. Does this include a fix to the class/juh.jar (problem 3 in <http://udk.openoffice.org/servlets/ReadMsg?list=dev&msgNo=4034>) not found problem? Is there a separate issue for that problem? (I didn't find any). We have an application JAR file that uses the SDK tooling method which fails with 3.0 beta. This application is deployed on over 5000 workplaces in different departments, so this is no small matter.
@mux2005: Yes, fix included. This issue is fixed on <http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fsb87>, integrated in forthcoming DEV300m19.
Created attachment 54508 [details] Testcase for simple bootstrap
@sb: I've just tried with 300m19 (Build 9317) under Windows and the classloader exception right at the beginning is indeed gone. However the bootstrap still doesn't work. It fails with Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.star.lib.loader.Loader.main(Loader.java:143) Caused by: com.sun.star.comp.helper.BootstrapException: no office executable fou nd! at com.sun.star.comp.helper.Bootstrap.bootstrap(Bootstrap.java:248) at de.muenchen.test.OOoBootstrapTest.main(Unknown Source) ... 5 more I have attached a test case. Run it with java -jar Test.jar Source code is included. To build it yourself: mkdir test cd test jar xf ..../Test.jar ant
@mux2005: The attached Test.jar contains com/sun/star/lib/loader/*.class files from an old SDK. As I wrote above: "The net result is that newly built Simple Bootstrap applications should work against old and new OOo installations, but old Simple Bootstrap applications will not work against new OOo installations."
@sb: I think you're confusing something here. The included loader classes are the tooling classes. They are responsible for getting the classpath set up correctly and getting the whole thing running. With m17 these classes were the point of failure. In other words, with m17 the program did not even get to point where main() is executed. This has apparently been fixed with m19. The NEW problem that Test.jar demonstrates with m19 is in the class com.sun.star.comp.helper.Bootstrap, which is NOT included in Test.jar. Look at the stack trace. We are executing main() here (the "Caused by..." line is the beginning of the relevant stack trace), so the tooling has already worked, successfully found the OOo installation and set up the classpath. But cssc.helper.Bootstrap doesn't work. To make things clearer I'll attach a new test case that does not use the tooling method. Adapt the classpath in the batch file to match your installation and then run runtest.bat from the same directory where the new Test.jar is stored. On my system it fails with Exception in thread "main" com.sun.star.comp.helper.BootstrapException: no office executable found! at com.sun.star.comp.helper.Bootstrap.bootstrap(Bootstrap.java:248) at de.muenchen.test.OOoBootstrapTest.main(OOoBootstrapTest.java:19) Here it is obvious that the failing code is in com.sun.star.comp.helper.Bootstrap.bootstrap().
Created attachment 54526 [details] New testcase that doesn't use tooling
Created attachment 54527 [details] Batch file to run the new testcase
@mux2005: "it is obvious that the failing code is in com.sun.star.comp.helper.Bootstrap.bootstrap()" Sure, but for bootstrap() to work properly it has to be used in a specific environment (it has to be loaded with a class loader for which NativeLibraryLoader can find an soffice executable, see javaunohelper/com/sun/star/comp/helper/Bootstrap.java:1.16 l. 241 ff), and the com/sun/star/lib/loader stuff sets up the specific environment, and had to be changed as the environment now has to be slightly different than it was before (the relevant class loader now has to have the office brand layer program directory on its search path). Did you try whether your original Test.jar works for you if you replace the contained com/sun/star/lib/loader class files with the new class files from DEV300m19?
> Sure, but for bootstrap() to > work properly it has to be used in a specific environment That would be a new requirement for 3.0. With OOo 2.x the no-tooling approach (i.e. just adding the relevant jars to the classpath and running the class) works fine and is/was IIRC the way presented in the dev guide. If this special environment is indeed required with OOo 3.0 that would be a great inconvencience, since it would mean that I can no longer just run test programs from Eclipse via Run As/Java Application as was possible with OOo 2.x > Did you try whether your original > Test.jar works for you if you replace the contained com/sun/star/lib/loader > class files with the new class files from DEV300m19? I would like to, but I've not found a prebuilt DEV300m19 SDK (e.g. http://ftp5.gwdg.de/pub/openoffice/extended/developer/DEV300_m19/ doesn't have one.) and have not got around to attempting to build it myself.
closed, checked on master