Hi Stephan,
i am for a cleanup and so for a clean solution for all 3. As Kay pointed
out the C++ solution is probaly not used very often.
Juergen
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:
1 C++ unoapploader on Unix (Linux, Solaris): Determines the location
of an soffice application, adds the soffice path to LD_LIBRARY_PATH (so
that the subordinate process finds the URE libraries, which used to be
located next to the soffice application), and then spawns the
subordinate process. This no longer works, as the URE libraries are now
located somewhere else.
2 C++ unoapploader.exe on Windows: Determines the location of an
soffice application, adds the soffice path to PATH (so that the
subordinate process finds the URE libraries, which used to be located
next to the soffice application), and then spawns the subordinate
process. This no longer works, as the URE libraries are now located
somewhere else.
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).
Problem 1 could most silently be fixed by adding symbolic links for all
the URE libraries to all brand layer program directories. The advantage
is that an old unoapploader continues to work against a new soffice
installation. The disadvantage is the somewhat dirty solution (quite a
number of symlinks, not for general use but just for unoapploader to be
happy).
Problem 2 cannot be silently fixed, however. The only solution I see is
to change the Windows unoapploader.exe as follows: Determine the
location of an soffice application and check whether there is an
executable called (say) ureinfo next to it. If yes (i.e., new soffice
installation) call it and (if successful exit status) use its stdout
data to extend PATH. If no (i.e., old soffice installation) extend PATH
with the soffice path, as before. In either case, proceed as before
(spawn subordinate application). The disadvantage, of course, is that
an old unoapploader will no longer work against a new soffice.
Given that problem 2 needs an incompatible solution, anyway, the
question is, for each of the problems 1 and 3, whether to go with a
compatible but somewhat dirty solution, or too go with a clean but
incompatible solution. (In all three cases the same sketched ureinfo
could be called by the loaders, parameterized on stdin whether to supply
information for C++ or for Java.)
For problem 1 my opinion is to go with the same solution as for problem
2 (i.e., call the sketched ureinfo on all platforms from the C++
unoapploaders, and thus have an incompatible change in the C++
unoapploaders of all platforms). For problem 3 I am somewhat undecided
(and, out of laziness, would probably go with the fake classes/juh.jar
wart, as it would be less work to implement).
More opinions, anybody?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
