Re: fdo#46808 - [Easy Hack] Adapt UNO services to new-style

On 03/22/2012 01:11 PM, Noel Grandin wrote:
> Diff attached.
[...]
> @@ -258,12 +259,7 @@ void SAL_CALL ResultSetImplHelper::connectToCache(
>          try
>          {
>              xStubFactory
> -                = 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?  ;)

Stephan