...instead of legacy __getServiceFactory. This fixes a subtle bug: When these
Java extensions are live-deployed, they are offloaded to an additional uno
process. Their __getServiceFactory methods were called with the uno process
(component context's) service manager, which they stored away for later use in
OneInstanceFactory.createInstance. So even if later on an instance was created
with the main LO process's component context, the uno process's component
context would be used to instantiate the (C++)
com.sun.star.linguistic2.LinguProperties service (in the uno process!), and that
happens to internally use comphelper::getProcessServiceFactory, which would be
null in the uno process,
comphelper::getProcessServiceFactory
comphelper::getProcessComponentContext
(anonymous namespace)::getConfigurationProvider
utl::ConfigManager::acquireTree
utl::ConfigManager::addConfigItem
utl::ConfigItem::ConfigItem
SvtLinguConfigItem::SvtLinguConfigItem
SvtLinguConfig::GetConfigItem
SvtLinguConfig::GetConfigItem
SvtLinguConfig::GetProperty
LinguProps::getPropertyValue
gcc3::callVirtualMethod
...
Change-Id: Ib6f5a5dd6d0adbbe14d60aaff3a8b6ba24235d11
