On 11/26/09 11:15, Steffen Boersig wrote:
To follow established expectations on the various platforms, and, in
some cases, due to technical necessities of the various platforms. In
principle, on all platforms there are three layers (URE, Basis, Brand)
at potentially arbitrary positions (even relative to each other).
Within the URE layer, one difference among platforms is that Windows
has both executables and libraries in bin, while Unix has libraries in
lib. Another difference is that, since recently, Windows shifted
virtually all libraries from the Basis program to the Brand program
directory.
Thanks for the info on that.
OOoBean tries to connect to soffice via a named pipe, which requires
native code in libjpipe.so being called from jurt.jar. I assume that
some Java error occurs failing to load that native lib which would be
swallowed by the "catch ( java.lang.Throwable aExc )" at OOoBean.java
l. 184. I suggest you patch OOoBean.java to include
"aExc.printStackTrace();" before "throw new NoConnectionException();"
to give more information.
I patched OOoBean.java (and to a minor extent PipeConnection.java) and
it seems you were right on this one. It's failing at the method
createJNI(String) with "xxx_25B7Office" as parameter.
After looking deeper into the subject I decided to test if my
referencing to jurt.jar and the others.
Indeed there was the problem.
Since the folder structure under Linux and Windows were different I
decided to fix it with symbolic links. It works fine for all loading
jars, but seems to cause trouble if a jar needs JNI functions.
I referenced with a new manifest file to the original locations instead
of symbolic links and it works just fine :)
Locating a native library loaded by a Java jar is typically done using
relative path entries in the jar manifest Class-Path. Resolving a
relative path relative to a symlink can obviously have different
results, depending on whether or not the symlink is resolved.
However, setting up infrastructure so that a (copied?) officebean.jar
finds its dependency jars will always be brittle and will likely break
with new OOo versions. What confuses me is that you need such
infrastructure at all.
What officebean.jar are you using? Is it the one located within the OOo
installation (at openoffice.org/basis3.x/program/classes/officebean.jar)
or is it a copy located somewhere else?
If the former (the officebean.jar located within the OOo installation),
its manifest Class-Path should contain links to all its dependency jars.
But that Class-Path is empty (the manifest does not contain one), at
least in DEV300m65, so this is probably a bug?
If the latter (a copy of officebean.jar located outside the OOo
installation), I wonder whether that is an intended way to use the bean,
and, if it is, could mention a stable way to obtain from an OOo
installation a list of jars (with absolute path) that are necessary in
order to use Java UNO. Namely, calling executable "unoinfo" in the brand
layer program directory with argument "java" (i.e.,
"openoffice.org3/program/unoinfo java") and processing its output (as
done by the Simple Bootstrap mechanism), see
<http://www.openoffice.org/issues/show_bug.cgi?id=88687#desc3>.
Anyway, maybe I misunderstand how officebean.jar is intended to be used,
Jochen (on cc) probably can put me straight.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
