Issue 110129 - configmgr no longer uses ini file and backend UNO API
Summary: configmgr no longer uses ini file and backend UNO API
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m74
Hardware: All All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2010-03-15 12:06 UTC by pulsifer
Modified: 2017-05-20 11:33 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description pulsifer 2010-03-15 12:06:31 UTC
A re-implementation of configmgr has been developed as part of i101955,
implemented as CWS sb111 and first integrated into the DEV300_m74 build.

In every version of OOo since 1.1.0, the configmgr has been an UNO component
with a well-defined interface.  In fact, the name of the UNO config service that
was loaded by OOo at startup was specified by the CFG_BackendService variable in
configmgr(rc|.ini).  This made it possible for downstream developers to
reimplement configmgr to adapt it to different platforms or environments by
simply changing the CFG_BackendService variable.  It was also possible for
downstream developers to insert new configuration layers into OOo's native
configmgr by modifying the CFG_Strata variable in configmgrrc.  See for example

The new version of configmgr is no longer a pure UNO component, and the
configmgr(rc|.ini) file has been completely removed, making it more difficult
for downstream developers to adapt OOo to other environments.

I would like to request that the reimplemented configmgr be given an UNO
interface, just like every other configmgr in OOo since v1.1.0.  In viewing the
source code, it appears two functions have been added that are directly linked
into the main application instead of using an UNO interface:
insertExtensionXcsFile and insertExtensionXcuFile.  I would like to request that
these two functions be reimplemented as an UNO service with a documented
interface.  (Alternatively, instead of these new functions, unopkg could send an
event using which configmgr picks up
using XEventListener and then re-scans the installed extensions directories.)

I would also like to request that the configmgrrc and the CFG_BackendService
variable be restored to allow OOo to be reconfigured by downstream developers.
Comment 1 Stephan Bergmann 2010-03-15 13:11:34 UTC
What the new configmgr implementation indeed no longer supports are the
configmgr ini file in the basis program directory and the ability to hook in
additional backends.  I was not aware that any client code used those features,
so took the liberty to drop them for simpler and potentially more efficient code.

The new configmgr still is a UNO component, however (I adapted this issue's
summary accordingly).  The private C++ interface between configmgr and the
extensions manager is an implementation detail; I see no need to revise it.

@pulsifer:  Do you have any specific usage scenarios that are broken now?
Comment 2 pulsifer 2010-03-15 14:36:15 UTC
As long as configmgr has a private C++ interface, it cannot be replaced by
another UNO component.  That of course is the whole point of the UNO framework
on which OOo is built and that was used by the former configmgr.  It would not
be difficult to implement the new functions as an UNO service that is accessed
through the UNO service registry (services.rdb), and that would bring the new
configmgr on par with the former implementation, which as I mentioned, has been
in OOo since v1.1.0.

I would also like to request that all of the directory paths used by the new
configmgr be put back into variables in the configmgrrc file.  This would
include all of the paths configmgr searches for .xcd, .xcu and .xcs files, as
well as the location where user data is stored.  The hard-coding of the paths is
a step backward from implementation that was in OOo from v1.0 to up to the
latest v3.2 release, and it no doubt had little effect on performance.  It again
makes OOo less usable by downstream developers and users with non-standard

Yes, I do have a particular usage scenario in mind: trying to integrate a custom
backend with the new configmgr.  This backend was implemented in the manner
described by in the post I linked to above.  It has run
fine under every version of OOo since v2.0 but does not work with the new
configmgr as it is currently implemented in CWS sb111.

Comment 3 Stephan Bergmann 2010-03-15 15:18:23 UTC
@pulsifer:  Out of curiosity, what does your additional backend do?

("As long as configmgr has a private C++ interface, it cannot be replaced by
another UNO component."  I assume this is only of theoretical interest, right?)
Comment 4 pulsifer 2010-03-15 15:52:19 UTC
>> "As long as configmgr has a private C++ interface, it cannot be replaced
>> by another UNO component."

>  I assume this is only of theoretical interest, right?

This is not a theoretical interest.  We would use this mechanism to implement
our our custom configuration layer, the one we have been using with OOo since
v2.0.  (The oor:external mechanism you added to the new configmgr is not
sufficient for our purposes.)  This would be simple change in the new configmgr,
and would bring it back on par with the configmgr that has been in OOo since
v1.1.0, which was an UNO component with a pure UNO interface.
Comment 5 Oliver Brinzing 2010-03-16 08:24:23 UTC
Comment 6 Stephan Bergmann 2010-03-17 10:19:39 UTC
@pulsifer:  I'm afraid there is no quick and easy way to bring back the feature
of hooking additional backends into the current configmgr.  I see two possible
ways ahead:
1  Replacing the C++ dependency between configmgr and extension manager with an
(unstable, for now) UNO interface would indeed be easy.  It would enable
replacing all the configmgr service implementations with your own
implementations of those services.  I am not sure this is what you want to do,
though (you do not currently do this, right?).
2  Designing the missing functionality into the new configmgr (using mechanisms
that are as close as reasonably possible to the old mechanisms).  For this, it
would be necessary that you provide a description of the exact
services/interfaces you used, and how you modified the configmgr ini file.
Comment 7 pulsifer 2010-03-23 01:54:38 UTC
After studying this issue for some time, it looks to me fairly straightforward
to pull an additional configuration layer into the new configmgr.  There are a
few related problems I see though: (1) how to notify the configmgr that the data
in an external layer has changed (would the external layer be polled, and if so,
when?); (2) what would the configmgr do when the external layer has changed
(does the entire config data tree need to be rebuilt, or just part of it, or can
the rebuild begin with an intermediary result?); and (3) would property change
notifications be sent to listeners when data changes in an external layer, and
if so, how?  My thought is that these issues require some experimentation, and
at this point, early in the v3.3 release cycle, I'm willing to do that, try to
figure out what will work best, and potentially offer some patch sets or further
feedback. I would still like to see the new configmgr have a purely UNO
interface though, so it would be easier to extend.
Comment 8 Stephan Bergmann 2010-05-14 09:39:34 UTC
"new configmgr have a purely UNO interface": issue 110491

"I'm willing to do": so passing this issue back to you for now
Comment 9 Marcus 2017-05-20 11:33:31 UTC
Reset assigne to the default "".