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

[Noel Grandin]

That was just about to be my next question :-)

How do I decide whether to change the constructor to take 
XComponentContext or XMultiComponentFactory?


On 2012-03-22 14:36, Stephan Bergmann wrote:
> 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
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>