Deployment Options for Components
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 OpenOffice.org. 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 com.sun.star.registry.SimpleRegistry 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 com.sun.star.reflection.TypeDescriptionProvider 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 OpenOffice.org 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 OpenOffice.org SDK.
$ 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 /UCR/com/sun/star/bridge/XUnoUrlResolver Value: Type = RG_VALUETYPE_BINARY 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, com/sun/star/connection/ConnectionSetupException, com/sun/star/lang/IllegalArgumentException 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.
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 OpenOffice.org, 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 com.sun.star.io.Pipe service.
$ regview services.rdb /SERVICES/com.sun.star.io.Pipe /SERVICES/com.sun.star.io.Pipe Value: Type = RG_VALUETYPE_STRINGLIST Size = 38 Len = 1 Data = 0 = "com.sun.star.comp.io.stm.Pipe"
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
$ regview services.rdb /IMPLEMENTATIONS/com.sun.star.comp.io.stm.Pipe /IMPLEMENTATIONS/com.sun.star.comp.io.stm.Pipe / UNO / ACTIVATOR Value: Type = RG_VALUETYPE_STRING Size = 34 Data = "com.sun.star.loader.SharedLibrary" / SERVICES / com.sun.star.io.Pipe / LOCATION Value: Type = RG_VALUETYPE_STRING Size = 8 Data = "stm.dll"
The implementations section holds three types of data.
- The loader to be used when the component is requested at runtime (here com.sun.star.loader.SharedLibrary).
- The services supported by this implementation.
- The URL to the file the loader uses to access the library (the url may be given relative to the OpenOffice.org library directory for native components as it is in this case).
|Content on this page is licensed under the Public Documentation License (PDL).|