ae3a0c8da5 unfortunately forgot to
implement mapping between UNO environments for constructor functions
in the UNO service manager, and due to the many componennt conversions
to constructor functions since then, the log UNO purpose environment
has become mostly useless.
Save the environment, create a closure today!
https://wiki.openoffice.org/wiki/Uno/Spec/Log_Environment
Change-Id: Idc03b5ed9529da8e81cd91efe50cbeceffa2b247
Reviewed-on: https://gerrit.libreoffice.org/33060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
...to directly call constructor functions of ComponentContext-based C++
implementations of (non-single-instance) UNO services. The case where these
calls would need to be bridged across different environments (e.g., from gcc3
to gcc3:affine) is not yet implemented.
bootstrap.component and expwrap.component are adapted accordingly as a proof-of-
concept (which had previously been adapted to use the prefix="direct" feature,
which may become unnecessary again in the end, depending on how to handle
single-instance services/singletons). More to follow.
Change-Id: I18682d75bcd29d3d427e31331b4ce8161dbb846d
...for internal loader="com.sun.star.loader.SharedLibrary" components, instead
of exported component_getImplementationEnvironmen (or implicit
CPPU_CURRENT_LANGUAGE_BINDING_NAME). Adapted a few .component files as proof-
of-concept, more to follow.
Change-Id: I82332e0a48e6fc1da245990bb72265fe6e58447e
...it was never meant to be called by client code anyway and is no longer needed
to be exposed since the global service manager implementation moved to
cppuhelper.
Change-Id: If2d0510b2364084d36edeb156a3459d9b8aeb983
