Now that we have default values for Exception constructor params,
remove lots of boilerplate code.
Change-Id: I620bd641eecfed38e6123873b3b94aaf47922e74
This reverts commit 67e69a5582, applying a band-
aid fix to cli_ure/source/climaker for now.
Conflicts:
stoc/inc/bootstrapservices.hxx
stoc/source/tdmanager/lrucache.hxx
stoc/source/tdmanager/tdmgr.cxx
stoc/source/tdmanager/tdmgr_common.hxx
stoc/source/tdmanager/tdmgr_tdenumeration.cxx
stoc/source/tdmanager/tdmgr_tdenumeration.hxx
Change-Id: Iae669985d0194f06fa349a4a39f0ebd230bc5d28
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Implement theTypeDescriptionManager directly on top of unoidl::Manager and
unoidl::Provider in cppuhelper instead of on top of css.reflection UNO
interfaces in stoc. Adapt desktop/source/deployment/ accordingly.
There is no longer a com.sun.star.reflection.TypeDescriptionManager service
implementation now, only a com.sun.star.reflection.theTypeDescriptionManager
singleton one, which appears to not cause problems in practice.
Change-Id: I179501272f0712353b7d50d3eba2ec2bb79db373
...to make it easier in the future to replace the binary rdb format with
something else, but also keep support for the old format for backwards
compatibility (extensions).
This should have no performance impact, as the type description manager (a)
caches information about requested type descriptions, and (b) has been changed
to process the bootstrap rdbs en bloc without doing costly consistency checks
(which are useful though when inserting an rdb when installing an extension, but
which would exhaustively read all type descriptions from the inserted rdb, so
would negate any benefit of constructing any type descriptions on demand only).
Change-Id: I80b22770bd9a5e0ab686f04d9c70295f2e3d0bf6
...instead of having to rely on the odd bootstrapInitialSF and explicit
loadSharedLibComponentFactory.
Change-Id: I2fb212024c483254da015db3af43d9002051dddc
...this was a transitional hack to get XML-format service.rdbs in. Now that
registry-based bootstrap_InitialComponentContext is gone, XML-format .rdbs need
only be handled in cppuhelper/source/defaultbootstrap.cxx (so the
textualservices stuff once duplicated to there now effectively moved there).
Change-Id: Ifb93558768095c1b462fe4057ebf8724968cca77
This changes all generated API headers (.hpp and .hdl) to use a
namespace alias 'css' instead of the pointlessly long com::sun::star
Makes the change in cppumaker & associated tools, adds a global
namespace alias definition in sal/types.h, and removes a kiloton
of local, now pointless-to-harmful versions of that alias from all
over the code.
Change-Id: Ice5a644a6b971a981f01dc0589d48f5add31cc0f
removeRdbFiles suffered from a confusion that ImplementationInfo.uri denotes the
corresponding component (.so, .jar, etc.), but not the .rdb file. So removing
an .rdb file silently failed to remove the corresponding implementations, so re-
installing a similar enough .rdb (as typically happens during extension update)
would fail due to duplicate implementation names.
Change-Id: I25d4ff72656c99a3af509eef09e89c18cfd0aabe
Erasing from data_ member maps can destroy contained Implementations, which in
turn releases the UNO objects referenced from there, which in turn can cause
XComponents to dispose, which in turn can call arbitrary code, so must not be
done with rMutex locked. Witness the backtrace at
<https://bugs.freedesktop.org/attachment.cgi?id=65142> linked from fdo#52639
(where this fix appears otherwise unrelated to that issue's main topic).
Change-Id: If55a3841b761ec1d9a0ef61fe54784426c4ee442
...in loadImplementation (instead of using the context the ServiceManager itself
was created with). Otherwise, the handcrafted context containing a fake
theJavaVirtualMachine singleton in install_vm_singleton
(javaunohelper/source/vm.cxx) would not be honored, so that if a Java process
bootstraps native (binary) UNO and from there tries to obtain that singleton, it
would erroneously try to instantiate another JVM instead of using the existing
one. This was a regression introduced with the new ServiceManager and could be
witnessed by test-javanative in ure/source/uretest/Makefile failing.
Change-Id: I58cfbc8cdaea7ee4ab80fac728ea3e85676d69e1
...as some client code catches just the former and thus fails now. (This was a
regression introduced with the recent cppuhelper/source/defaultbootstrap.cxx.)
Change-Id: I8306797f8331d894ab4e7695478e3824e9f79197
This reverts commit b162aec625, which increased
code complexity for no benefit (the dubious scenario it was introduced for
concerned duplicate service rdbs rather than type rdbs, anyway).
...see comment in ServiceManager::createContentEnumeration for a rationale.
Splitting ImplementationInfo out of Implementation has become necessary to avoid
circular references.
Change-Id: I29aef81ce78b9ab71e18663f8c7e6ca913c6a650
...that no longer uses XSimpleRegistry structures for the service data and thus
is potentially more performant.
* Registry-based functions from cppuhelper/bootstrap are deprecated now, client
code should always use defaultBootstrap_InitialComponentContext.
* References to the obsolete UNO_WRITERDB have been removed.
* Some of the functions in cppuhelper/source that are used from multiple .cxx
but had not been properly placed into .hxx have been cleaned up.
* css.lang.ServiceManager XSet insert/remove now support special
sequence<NamedValue> to improve live deployment/removal of XML-based extension
components data.
* 09524d410b "stoc: accelerate opening of multiple
XML .rdb files in a directory" and its follow-up
cb5c881a7f "avoid using the new rdb reading
logic for empty/non-existent directories" have been obsoleted by this change
and have been reverted again.
