Stephan,
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.
thanks for the overview ...
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).
I see ... I suggest to sacrifice compatibility and to see how many are
starting to scream, only if we feel that these are too many, we should
add any compatibility hacks.
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).
Again I suggest to sacrifice compatibility and _not_ to add any links,
as far as I can tell, the C++ stuff is even less often used then the
Java stuff.
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.
Same suggestions as for 1) and 2).
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.)
Let's go with the clean approach ...
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).
I think going with the clean solution is what we should do, a workaround
for older code is to manually set the UNO_PATH env. var. to point to the
URE.
One obvious solution, at least for the Unices, would have been, to put
the starters (unoapploader, juh.jar (respectively the loader part of
it)), at persistent locations of the target system ...
More opinions, anybody?
-Stephan
Kay
---------------------------------------------------------------------
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]
