fdo#46808 - [Easy Hack] Adapt UNO services to new-style
sbergman at redhat.com
Thu Mar 22 05:36:18 PDT 2012
On 03/22/2012 01:11 PM, Noel Grandin wrote:
> Diff attached.
> @@ -258,12 +259,7 @@ void SAL_CALL ResultSetImplHelper::connectToCache(
> - = uno::Reference<
> - com::sun::star::ucb::XCachedDynamicResultSetStubFactory >(
> - m_xSMgr->createInstance(
> - rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(
> - "com.sun.star.ucb.CachedDynamicResultSetStubFactory" )) ),
> - uno::UNO_QUERY );
> + = com::sun::star::ucb::CachedDynamicResultSetStubFactory.create();
Note that UNO service constructors, in the C++ and Java language
bindings, take the XComponentContext as an additional first argument.
In your example, ResultSetImplHelper does not have a component context
around, only an XMultiServiceFactory m_xSMgr (because it is old code,
written before the XComponentContext/XMultiComponentFactory concept
replaced the now-obsolete XMultiServiceFactory concept).
As a quick fix, you can pass comphelper::getProcessComponentContext()
(#include "comphelper/processfactory.hxx") into create(), but you
unfortunately cannot even commit that, as it violates module
dependencies (comphelper depends on ucbhelper, so ucbhelper cannot
depend on comphelper). The right fix is to change the
ResultSetImplHelper constructor and adapt all its uses accordingly.
Did I speak about an odyssey? ;)
More information about the LibreOffice