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

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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice