I'm currently working on a new configmgr backend, dbbe. The goal of
this work is to make oo.o start much faster by eliminating disk seeks
for config data. There is a more thorough description of this on the
wiki at: http://wiki.services.openoffice.org/wiki/DbConfig)
I'm having a bit a trouble with UNO in configmgr. The way that
configmgr registers its services in configunoreg.cxx is a little
confusing to me.
In configmgr/source/localbe/localmultistratum.cxx (transposed with some
values to make it easier to read), we define a
/// The implementation name of this service implementation
/// The services for which this service implementation is registered
/// Additional services implemented by this service implementation, for
which it is not registered
This goes to configunoreg.cxx:
How these names map to API is not clear to me. There is an idl file
MultiLayerStratum.idl, which defines the service MultiLayerStratum. I
can't seem to find anywhere that has idl for LocalMultiStratum or
MultiStratum. Am I missing something? How can this work? Of course, I
need to use a similar structure to define the same service for my
backend, dbbe. It's unclear to me what magic strings I should supply
for the ServiceImplementationInfo struct. Any clues are appreciated.
Software Engineer, Channel Software Operation
michael.leibowitz at intel.com
+1 503 264 7621
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]
> Hi, all
> I'm currently working on a new configmgr backend, dbbe. The goal of
> this work is to make oo.o start much faster by eliminating disk seeks
> for config data. There is a more thorough description of this on the
> wiki at: http://wiki.services.openoffice.org/wiki/DbConfig)
> I'm having a bit a trouble with UNO in configmgr. The way that
> configmgr registers its services in configunoreg.cxx is a little
> confusing to me.
Apparently some things aren't as well maintained as they should be there
(mea culpa). Today I would probably do that differently.
But if you implement your backend as a separate component (i.e. shared
object) [as you probably should], then you'll need to implement your own
> In configmgr/source/localbe/localmultistratum.cxx (transposed with some
> values to make it easier to read), we define a
> struct ServiceImplementationInfo
Note that this way of defining service information pertains to the
deprecated 'old style' UNO services - a hierarchy of abstractions with
little concrete significance, as you can see below. Today 'new style'
services should be used. Here the functional hierarchy is made through
(multiple inheritance of) interfaces and a service is defined mainly for
instantiation. The configuration backend stuff is all old style and if
it ever is migrated to new style services it should be done globally. So
you should probably stick to old style services for your backend.
> /// The implementation name of this service implementation
This is an implementation name. That is simply a name for a particular
implementation of a set of abstract services. That name should be
globally unique and parts of the OOo codebase have adopted the
"com.sun.star.comp.*" namespace for this.
This name can be used as pseudo service name for instantiating a
specific implementation instead of (an arbitrary implementation of) an
> /// The services for which this service implementation is registered
This is not a single name, but a list of service names. These names will
be registered in the services database (generally services.rdb) and can
be used to instantiate this component. If multiple components register
the same service it is unspecified which component will be chosen for
instantiation. It is possible to enumerate all registered
implementations and instantiate some or all of them.
These services should have associated IDL (but see below).
> /// Additional services implemented by this service implementation, for
> which it is not registered
This again is a list of service names. These are abstract services that
the component implements, but for which it will not register in the
services database. Generally these services are so generic, that they
are implemented by multiple components so they can't meaningfully be
used to instantiate a component. This list together with the previous
one should comprise all its directly or indirectly inherited abstract
services. Both lists together are used to implement the XServiceInfo
All these services should have associated IDL (but see below).
> This goes to configunoreg.cxx:
Yes. These structures are used to implement UNO boilerplate.
> How these names map to API is not clear to me. There is an idl file
> MultiLayerStratum.idl, which defines the service MultiLayerStratum. I
> can't seem to find anywhere that has idl for LocalMultiStratum or
> MultiStratum. Am I missing something?
Not really. What you found are bugs - but not high-priority ones, as the
configuration backend API is not intended for direct consumption by user
code and these things don't affect the function of the configuration
itself. The localbe multi-stratum was added in a hurry under time
pressure, to fix the installation of the configuration for deselectable
modules. Apparently the IDL handling was lacking.
The concrete bugs are:
- There should be IDL defining service
com.sun.star.configuration.backend.LocalMultiStratum, just like there is
for LocalSingleStratum. Services used for some of the SingleStratum
variations ('Res', 'Data', ReadOnly') should also get IDL descriptions.
The new IDL would probably classified as non-'published' atm, but it
should still exist.
- Use of "com.sun.star.configuration.backend.MultiStratum" is an error,
it should be "com.sun.star.configuration.backend.MultiLayerStratum" instead.
> How can this work?
The IDL for abstract services is primarily documentation. A component
can be registered as implementing a service and instantiated using that
service name even if there is no IDL for the service. No inference of
inherited services or verification of implemented interfaces is done at
runtime. The one function that is broken is when all implementations of
some of these services are enumerated. But for LocalMultiStratum there
is only one and the backend is intentionally not registered as
implementation of c.s.s.c.backend.Multi[Layer]Stratum, because there is
not much sense in enumerating them all.
One place where this would cause errors is automated API testing. But to
be included there, the implementation must also be enumerated in the
component description XML file. Without checking, I assume that that one
wasn't updated either ...
> Of course, I
> need to use a similar structure to define the same service for my
> backend, dbbe. It's unclear to me what magic strings I should supply
> for the ServiceImplementationInfo struct. Any clues are appreciated.
You only need to create that struct, if you actually reuse my arcane
mechanism. But you'll need the same data anyhow.
Implementation name is arbitrary. Could be
DbbeXxxStratum). Or it could be
Similar for the very-specific-but-theoretically-still-abstract service
name which is intended to be used for instantiation (but with out the
"comp"). That service, in its IDL, should inherit SingleLayerStratum or
MultiLayerStratum (as appropriate), so that respective service should be
listed in one of the service name lists as well.