ae855bf481
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> |
||
|---|---|---|
| .. | ||
| com/sun/star/comp/bridge | ||
| qa | ||
| source | ||
| CustomTarget_bridgetest.mk | ||
| CustomTarget_bridgetest_climaker.mk | ||
| CustomTarget_bridgetest_javamaker.mk | ||
| CustomTarget_uno_test.mk | ||
| InternalUnoApi_bridgetest.mk | ||
| InternalUnoApi_performance.mk | ||
| Jar_testComponent.mk | ||
| Library_bridgetest-common.mk | ||
| Library_bridgetest.mk | ||
| Library_constructors.mk | ||
| Library_cppobj.mk | ||
| Makefile | ||
| Module_testtools.mk | ||
| Rdb_uno_services.mk | ||
| README | ||
Testing tools == How to check compatibility between compilers == Since the interfaces used in the cpp bridgetest are not changed often one can just build the cppobj.uno.dll and the constructors.uno.dll (testtools/source/bridgetest) in an old environment and then use them in the new environment. That is the files are copied into the testtools/wntmsciXX.pro folder which corresponds to the new environment. On Windows this test will typically fail because the tests use the cppu::getCaughtException function, which only works when all libs are build using the same runtime. This part of the test can switched off. To do this go into the testtools/source/bridgetest folder and call dmake compcheck=1 This will add a new compiler define (-DCOMPCHECK) and will be used in the bridgetest.cxx to switch off the code which uses the getCaughtException function. However, there is still a test which causes the test component to throw and IllegalArgumentException. This still works. == Using source/bridgetest for stress testing == Start a modified bridgetest_server (with the final "--singleaccept" argument removed from the uno executable call) or a modified bridgetest_javaserver (with the final "singleaccept" argument replaced with "multi" in the java executable call), then start a modified bridgetest_client (with a final "stress" argument added to the uno executable call). The client will continuously establish connections to the server which are immediately destroyed again. The test will run forever, unless an error occurs.