Deployment Options for Components

From Apache OpenOffice Wiki
Jump to: navigation, search

Component are usually distributed and deployed as extensions (see chapter Extensions). However, by using legacy tools, such as regcomp, and regmerge, it is also possible to install components, which can be more convenient during development.

Background: UNO Registries

This section explains the necessary steps to deploy new UNO components manually into an installed Background information is provided and the tools required to test deployment are described. The developer and deployer of the component should be familiar with this section. If the recommendations provided are accepted, interoperability of components of different vendors can be achieved easily.

UNO registries store binary data in a tree-like structure. The stored data can be accessed within a registry programmatically through the service, however this is generally not necessary. Note that UNO registries have nothing to do with the Windows registry, except that they follow a similar concept for data storage.

UNO-registries mainly store two types of data :


To invoke UNO calls from BASIC or through an interprocess connection, the core UNO bridges need information about the used data types. UNO stores this information into a type library, so that the same data is reusable from any bridge. This is in contrast to the CORBA approach, where code is generated for each data type that needs to be compiled and linked into huge libraries. Every UNOIDL type description is stored as a binary large object (BLOB) that is interpreted by the service.

Information about registered components

One basic concept of UNO is to create an instance of a component simply by its service name through the ServiceManager. The association between the service name and the shared library or .jar-file where the necessary compiled code is found is stored into a UNO-registry.
The structure of this data is provided below. Future versions of will probably store this information in an XML file that will make it modifiable using a simple text editor.

Both types of data are necessary to run a UNO-C++ process. If the types of data are not present, it could lead to termination of the program. UNO processes in general open their registries during startup and close them when the process terminates. Both types of data are commonly stored in a file with an .rdb suffix ( rdb=registry database ), but this suffix is not mandatory.

UNO Type Library

All type descriptions must be available within the registry under the /UCR main key (UCR = Uno Core Reflection) to be usable in a UNO C++ process . Use the regview tool to view the file <officepath>/program/types.rdb. The regview tool comes with the SDK.

For instance:

 $ regview types.rdb /UCR 

prints all type descriptions used within the office to stdout. To check if a certain type is included within the registry, invoke the following command:

 $ regview types.rdb /UCR/com/sun/star/bridge/XUnoUrlResolver 
   Size = 461 
   Data = minor version: 0 
   major version: 1 
   type: 'interface' 
   name: 'com/sun/star/bridge/XUnoUrlResolver' 
   super name: 'com/sun/star/uno/XInterface' 
   Doku: "" 
   number of fields: 0 
   number of methods: 1 
   method #0: com/sun/star/uno/XInterface resolve([in] string sUnoUrl) 
   raises com/sun/star/connection/NoConnectException,
   Doku: "" 
   number of references: 0

The regview tool decodes the format of the BLOB containing the type description and presents it in a readable form.

Component Registration

The UNO component provides the data about what services are implemented. In order not to load all available UNO components into memory when starting a UNO process, the data is assembled once during setup and stored into the registry. The process of writing this information into a registry is called component registration. The tools used to perform this task are discussed below.

For an installed, the services.rdb contains the component registration information. The data is stored within the /IMPLEMENTATIONS and /SERVICES key. The code below shows a sample SERVICES key for the service.

 $ regview services.rdb /SERVICES/
        Size = 38 
        Len  = 1 
        Data = 0 = ""

The code above contains one implementation name, but it could contain more than one. In this case, only the first is used. The following entry can be found within the IMPLEMENTATIONS section:

 $ regview services.rdb /IMPLEMENTATIONS/
 / UNO 
                      Size = 34 
                      Data = ""
                   Size = 8 
                   Data = "stm.dll"

The implementations section holds three types of data.

  1. The loader to be used when the component is requested at runtime (here
  2. The services supported by this implementation.
  3. The URL to the file the loader uses to access the library (the url may be given relative to the library directory for native components as it is in this case).
Content on this page is licensed under the Public Documentation License (PDL).
Personal tools
In other languages