Stephan Bergmann wrote:
Unfortunately, with the advent of the Three-Layer Office
(<http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo>,
starting DEV300m4) both 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. The problems are as follows:
... cut ...
3 Java com.sun.star.lib.loader.Loader: Determines the location of an
soffice application, locates classes/juh.jar relative to the soffice
path, calls com.sun.star.comp.helper.UnoInfo.getJars there (which
returns the list of URE jar URLs), and loads the subordinate
application in a class loader that knows the URE jars. This no longer
works, as juh.jar is now located somewhere else.
Problem 3 could most silently be fixed by adding a fake
classes/juh.jar (containing only a modified
com.sun.star.comp.helper.UnoInfo.getJars that returns the correct list
of URE jar URLs) to each brand layer. The advantage is that an old
Loader continues to work against a new soffice installation. The
disadvantage is the somewhat dirty solution (have a classes subdir
only for the fake juh.jar, have a fake juh.jar with the same name as
the true juh.jar in the URE).
... cut ...
Just a question here:
in order to allow for using OOo 2.x from Java, I have a setup
routine that defines the classpath to point to
"OOoHome/program/classes/jurt.jar",
"OOoHome/program/classes/unoil.jar",
"OOoHome/program/classes/ridl.jar", and
"OOoHome/program/classes/juh.jar".
Would that setup still work for OOo 3.x? If not, what is the
recommended setup for classpath then?
TIA,
---rony
