Issue 88687 - C++/Java Simple Bootstrap broken
Summary: C++/Java Simple Bootstrap broken
Status: CLOSED FIXED
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: jsc
QA Contact: issues@api
URL:
Keywords:
: 89770 (view as issue list)
Depends on:
Blocks:
 
Reported: 2008-04-24 12:29 UTC by Stephan Bergmann
Modified: 2013-02-24 21:08 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Testcase for simple bootstrap (16.01 KB, application/octet-stream)
2008-06-16 13:08 UTC, mux2005
no flags Details
New testcase that doesn't use tooling (3.49 KB, application/octet-stream)
2008-06-17 09:04 UTC, mux2005
no flags Details
Batch file to run the new testcase (350 bytes, text/plain)
2008-06-17 09:04 UTC, mux2005
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Comment 1 Stephan Bergmann 2008-04-24 12:30:56 UTC
.
Comment 2 Stephan Bergmann 2008-05-07 12:54:48 UTC
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.
Comment 3 Stephan Bergmann 2008-05-14 09:05:01 UTC
@jsc: please verify
Comment 4 jsc 2008-05-15 12:38:02 UTC
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.
Comment 5 Stephan Bergmann 2008-06-02 15:01:37 UTC
*** Issue 89770 has been marked as a duplicate of this issue. ***
Comment 6 mux2005 2008-06-10 12:29:05 UTC
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. 
Comment 7 Stephan Bergmann 2008-06-10 12:54:56 UTC
@mux2005:  Yes, fix included.  This issue is fixed on
<http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fsb87>,
integrated in forthcoming DEV300m19.
Comment 8 mux2005 2008-06-16 13:08:36 UTC
Created attachment 54508 [details]
Testcase for simple bootstrap
Comment 9 mux2005 2008-06-16 13:13:28 UTC
@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
Comment 10 Stephan Bergmann 2008-06-16 16:25:58 UTC
@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."
Comment 11 mux2005 2008-06-17 09:02:57 UTC
@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().

Comment 12 mux2005 2008-06-17 09:04:01 UTC
Created attachment 54526 [details]
New testcase that doesn't use tooling
Comment 13 mux2005 2008-06-17 09:04:40 UTC
Created attachment 54527 [details]
Batch file to run the new testcase
Comment 14 Stephan Bergmann 2008-06-17 09:24:04 UTC
@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?
Comment 15 mux2005 2008-06-17 11:08:29 UTC
> 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.

Comment 16 jsc 2008-07-29 15:15:34 UTC
closed, checked on master