|
Reference<XComponentContext> SAL_CALL defaultBootstrap_InitialComponentContext()
SAL_THROW((Exception));
Reference<XComponentContext> SAL_CALL defaultBootstrap_InitialComponentContext(
const OUString & iniFile) SAL_THROW((Exception));
The first function views UNO itself as a subsystem in the sense of microdeployment, the
subsystems name is, as might be expected, uno. Please look at the microdeployment
for a more comprehensive explanation of subsystems. The second allows to pass the
subsystems name. This e.g. usable while building a new subsystem which should not
use UNO default configurations.
The bootstrap parameters for UNO are the following:
setenv UNO_TYPES "first.rdb second.rdb third.rdb"
The UNO parameters can be given via command line, environment variables, via an optional unorc/uno.ini or via an application specific rc/ini file. If they are not defined by any of these ways, they are searched beneath the cppuhelper library with the subsystems name, expanded with the appropriate suffixes, which are "_types.rdb" respectivly "_services.rdb". E.g. the full names would be "uno_types.rdb" respectivly "uno_services.rdb". Certainly this only holds true, if using the first function, if using your own subsystems name, the uno prefix would be replaced with the given parameter.
int main(void) {
Reference xComponentContext =
defaultBootstrap_InitialComponentContext();
...
}
Alternatively a libraries/subsystems init function may looks like this:
int createSomeThinh(void) {
OUString libraryFileUrl;
Module::getModuleUrl((void *)createSomeThinh, libraryFileUrl);
// cut the library extension
iniName = libraryFileUrl.copy(0, libraryFileUrl.lastIndexOf((sal_Unicode)'.'));
// add the rc file extension
iniName += OUString(RTL_CONSTASCII_USTRINGPARAM(SAL_CONFIGFILE("")));
Reference xComponentContext =
defaultBootstrap_InitialComponentContext(iniName);
...
}
The library code uses the librarys name as the subsystem name and passes it to defaultBootstrap_InitialComponentContext. To get a libraries name, the method getModuleUrl can be used, this method takes a pointer as parameter and tries to locate the belonging library.
OpenOffice uses the same file as types and as services rdb. It also uses a user dependent writeable rdb, which should be located in the users configuration directory.
Typically a unorc in an office installation looks like this:
[Bootstrap] UNO_TYPES=$SYSBINDIR/applicat.rdb UNO_SERVICES=$SYSBINDIR/applicat.rdb
And the sofficerc looks like this:
[Bootstrap] Logo=1 UNO_WRITERDB=$SYSUSERCONFIG/.user60.rdb