Cedric Bosdonnat wrote:
Stephan Bergmann a écrit :
2 Start a Java process that bootstraps a native UNO environment in
process via
com.sun.star.comp.helper.Bootstrap.defaultBootstrap_InitialComponentContext
(see test-javanative in ure/source/uretest/Makefile[.pln] for an
example). That way, the returned XComponentContext gives you access to
an environment where the information from types.rdb and services.rdb is
accessible.
Good to hear that this is possible: it would be the same way for OOo and
the URE. However as explained upper, there are still some bugs and I'll
wait for them to be fixed on every platform.
Do you have any issue numbers and/or specific problem descriptions?
I just have talked about that with Juergen and he told me that it will
be fixed. I don't have any issue number for this. When I used this
bootstrap from a class loaded by a custom ClassLoader I got an error
like (I don't recall the exact wording): "No mapping found: C++ <-> Java".
Ah, that one. Now that you mention a custom ClassLoader, there are
probably two problems involved here:
First, the defaultBootstrap_InitialComponentContext code in juh.jar
needs to load a native juh shared library. This works if (a) juh.jar is
loaded by a classloader derived from URLClassLoader and (b) the loaded
juh.jar is from an OOo or URE installation (where the native juh shared
library is found "close" to it, in a well-defined relative position).
Second, if the native juh shared library can be found, it can still fail
to find other shared libraries it depends on, especially on Windows (are
you working on Windows?).
AFAIK, Jürgen is attacking the second problem only, so you need to make
sure that you are not affected by the first problem (i.e., what kind of
classloader is used to load juh.jar from where?).
-Stephan
Cedric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
