| Age | Commit message (Collapse) | Author |
|---|
|
jurt.jar and unoil.jar are kept as effectively empty jars, each with a
Class-Path: ridl.jar
in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or
without also loading ridl.jar) will still have access to their content.
Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi)
are not part of the URE, but are now made available by URE's ridl.jar. This
should probably not cause problems in practice.
At least for now, we seal exactly those packages in ridl.jar that were
originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now,
but that would be mildly incompatible, as it would prevent 3rd-party code from
introducing additional UNOIDL entities in the relevant namespaces (even if that
is something we do not want 3rd-party code to do anyway).
However, some JunitTest_jurt_* define classes in those sealed packages. In the
past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt.
Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the
gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes
that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the
UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the
udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests
get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use
gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets
leave that for a follow-up clean up.)
As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/.
Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Revert changes making HSQLDB related unit tests test Firebird migration.
They should still test the HSQLDB driver.
It reverts part of 159dd28651788a19848eae56693ad06ed947414d
Change-Id: If2b9207e95055418bd1dc1dc6e472335de311d1e
Reviewed-on: https://gerrit.libreoffice.org/52873
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
|
|
Also make Firebird driver not experimental anymore.
With hsql migration enabled, the hsqldb related unit tests can be
reused, because the underlying DBMS is transparent. To achieve that, I
added firebird_sdbc component to hsqldb CppunitTest_* files.
This commit also contains fixes for upcoming bugs while migrating from
hsqldb to firebird, shown by hsqldb related unit tests:
- null values: in case of null values, the setNull method should be used
instead of nothing. (malformed string otherwise)
Remove DBACCESS_HSQL_MIGRATION environment variable, since migration is
default from now on.
JunitTest_dbaccess_complex was based on HSQLDB. This commit replaces
"if exists" hsql specific solution with firebird specific. Also disable
test for queries with named parameters.
Change-Id: Ieb68f5ad3a11389599c4f268ea4df82a83643b82
Reviewed-on: https://gerrit.libreoffice.org/52008
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
|
|
If the object being finalized (A) has the last reference to the UNO object (B),
and B is actually a proxy for a remote UNO object, then A and B become eligible
for finalization in parallel, and the finalizer of B may already have run when
the finalizer for A runs. That means that B may already have been removed from
the remote bridge, causing an "unknown OID" error from the remote end when the
finalizer of A now tries to make a call on B.
(We try to assert that close() has actually been called before finalize() calls
delete(), but the corresponding exception may be silently swallowed by the JVM
finalization machinery.)
This caused spurious "URP: queryInterface request message with unknown OID
received" failures during JunitTest_dbaccess_unoapi.
Change-Id: Ia47c3ef2c22a6adc75b1b8271eb4b3140accebe7
|
|
and just use OOoRunner, there is no point in having a stripped down
jar, the cost of firing up the Java VM completely dwarfs any benefit
of having a smaller jar.
Change-Id: Ibcc3c5bd6e9b9c918041142dd32db0ea5dddc25b
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
|
|
Change-Id: I9f49970e5e06d1afd3fc066a20d1671c93e262fc
|
|
Change-Id: I0bca38ff0983fab3fa388cd0b4030caa520d10a5
|
|
|
