Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On 09/14/2013 09:14 AM, Andrzej Hunt wrote:
I've been trying to track down why the jvm isn't usable in unit tests
(attempted fix in https://gerrit.libreoffice.org/#/c/5936/ )

stoc/source/javavm/javavm.cxx needs to find java which it does by
expanding URE_INTERNAL_JAVA_DIR. This seems to be set within "unorc",
which is found automatically by cppuhelper (cppuhelper/source/paths.cxx
-- getUnoIniuri()) -- this loads unorc from wherever cppuhelper library
is  found(called libuno_ccpuhlpergcc3.so -- not sure why this is the
naming scheme?).

Running LO from instdir: instdir/unxlngx6/ure/lib/unorc is used
(generated by scp2/source/ooo/ure.scp) -- this contains the expected
URE_INTERNAL_JAVA_DIR

Running unit tests -- seems to happen in solver/, and
solver/unxlngx6/lib/unorc is used (directly copied from
cppuhelper/source/unorc), this one  doesn't contain any JAVA paths so
the jvm can't be loaded.


I've just hardcoded the new path into cppuhelper/source/unorc .
I don't know enough about the instdir changes to know whether this is a
good long term solution though?

There is also the classpath variable -- in the instdir unorc this is set
as
URE_INTERNAL_JAVA_CLASSPATH=${URE_MORE_JAVA_TYPES}

URE_MORE_JAVA_TYPES is set in fundamentalrc, of which there is also a
copy in solver (but under installation/program/...), I'm still looking
into whether this is loaded too in a unit test environment, but for the
moment I've just copied the same URE_INTERNAL_JAVA_CLASSPATH line: I
haven't tested yet whether this works -- I'll try that next.

Looks to me like using in-process Java-UNO has never worked in CppunitTests (and has never been needed before). Adding URE_INTERNAL_JAVA_CLASSPATH isn't currently needed (and there's no code that sets URE_MORE_JAVA_TYPES in any of the cases that use solver's unorc anyway), so I pushed <https://gerrit.libreoffice.org/#/c/5936/> without that part now as <http://cgit.freedesktop.org/libreoffice/core/commit/?id=6eb840cc540bb6f2efcebc0349a8e6e7ba074cd8> "Set URE_INTERNAL_JAVA_DIR for unorc to allow jvm in unit tests."

What I'm still not able to do is have hsqldb itself load (fails on can't
find org.hsqldb.jdbcDriver or similar) --this is since the driver has
the hsqldb.jar path hardcoded in the sources as
"$BRAND_BASE_DIR/" LIBO_SHARE_JAVA_FOLDER "/hsqldb.jar"
(and the jdbc drivers specifically only load classes from the driver
specific classpath) -- I guess if unit tests were to be run in instdir
then that would allow things to work, I'm still thinking about how best
to let them run in the current solver though (although I hear solver is
to be gotten rid of eventually).

The real problems were that (1) recent instdir changes had broken the ability to use solver's jvmfwk lib in "direct mode," which instantiating a JVM in the CppunitTest process would want to do, fixed with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=a041f518afe083f997660eb8f809df7f20c30fed> "Still copy jvmfwk support files to solver;" and (2) the connectivity drivers use jfw_getEnabled which does not work in that "direct mode," fixed with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=429042021590c80afb25ade833269635a24f2778> 'Make Java-based connectivity drivers work with jvmfwk "direct mode.'"

With all those fixes in, <https://gerrit.libreoffice.org/#/c/5934/> "Implement hsqldb loading test" now worked locally for me.

(Much of the above will become moot soon of course, when solver is done away with.)

Stephan

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.