You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <Fe...@day.com> on 2007/07/12 09:36:37 UTC
Configuration Admin Extension
Hi all,
Currently the Felix Config Admin implements the spec and as such
provides the configuration objects as required. What we are missing here
in one our projects is some kind of default configuration.
As far as I understand the specs, the Configuration Admin provides
configuration to ManagedService[Factory] objects. In addition the
Declarative Services specification defines, that the declared components
must be provided with Configuration Admin configuration (if the service
and such configuration is available) overwriting any declared properties
in the component declarations.
Our issue now is, that in some cases the default configuration inside
the ManagedService[Factory] objects or the declared components are not
sufficient for the application but the Configuration Admin does not have
any configuration yet to overwrite the defaults. We came up with the
idea of supporting such initial configuration to the Configuration Admin
inside of deployed bundles. Some service would pick up this
configuration and add it to the Configuration Admin.
So here is, what I propose:
The ConfigurationManager of the Felix Config Admin listens for bundle
changes. Whenever a bundle is installed, a special bundle manifest
header - e.g. Felix-Configuration - would be read, which contains a
comma-separated list of bundle entries. Each entry contains one or more
configurations to be added to the Configuration Admin. The
configurations from the bundles would be added to the Configuration
Admin using the permissions of the bundle providing the configuration.
Configuration is only added. That is, for normal configurations
(non-factory), the configuration is only added if no configuration with
the given service.pid already exists. For Factory configuration, the
given configuraiton would only be added if no factory configuration for
the given service.pid already exists. (In the future support for
configuration update/enhancement might be added, but this is a wide open
field, which I would not want to touch yet).
What do you think ? Would such an extension make sense to other people ?
Is the conceptual approach correct ?
I will provide a prototype implementation shortly in a JIRA issue for
further consideration.
Thanks for any feedback on this.
Regards
Felix
Re: Configuration Admin Extension
Posted by "Steven E. Harris" <se...@panix.com>.
Felix Meschberger <Fe...@day.com> writes:
> Configuration is only added.
I wrote a similar system inspired by the
PropertyFileConfigurationInitializer described here:
https://scm.ops4j.org/repos/ops4j/laboratory/users/bschmaus/net.tucana.osgi.impl.config/README
In my version, the application of configurations can observe one of four
modes:
o Defer
If an existing configuration exists for this PID, don't apply the
provided configuration.
o Underlay
If an existing configuration exists for this PID, only apply
settings from the provided configuration that are not specified in
the existing configuration. Don't overwrite anything.
o Overlay
If an existing configuration exists for this PID, apply settings
from the provided configuration on top of the existing
configuration as a set union of the two, leaving existing settings
in place that are not part of the provided configuration.
o Clobber
If an existing configuration exists for this PID, remove all its
settings and replace them with those in the provided
configuration.
There's an optional optimization to the update policy: For all modes but
"Defer", we check a message digest of the provided configuration's
Properties file against a revision stamp stored in an existing
configuration. If the digests match, we conclude that the existing
configuration doesn't need to be updated -- meaning that it was
contributed at some point in the past from the same Properties file.
We can't detect whether the configuration has been tampered with without
computing some canonical hash of the existing configuration itself and
comparing against the would-be provided configuration. I punted on that
for now.
Let me know if you'd like more detail.
--
steven E. Harris
Re: Configuration Admin Extension
Posted by Carsten Ziegeler <cz...@apache.org>.
BJ Hargrave wrote:
> Have you looked at section 115 Auto Configuration in the OSGi R4 Mobile
> spec? I think it does what you want.
Hmm, yes I think this is nearly what we are looking for with the
exception that we would like to configure "foreign bundles" as well.
(And the syntax for the configuration is quiet heavy - but that's a
different problem).
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Configuration Admin Extension
Posted by Felix Meschberger <fm...@gmail.com>.
Wow !
I have to admit that I did not have a look at the 4.1 spec yet, so I did
not realize there was a whole bunch of new service specs.
I will of course now go back and start reading.
Thanks for the hint.
Until then I think, this idea is just to be dropped :-)
Regards
Felix
Am Donnerstag, den 12.07.2007, 08:25 -0400 schrieb BJ Hargrave:
> Have you looked at section 115 Auto Configuration in the OSGi R4 Mobile
> spec? I think it does what you want.
Re: Configuration Admin Extension
Posted by BJ Hargrave <ha...@us.ibm.com>.
Have you looked at section 115 Auto Configuration in the OSGi R4 Mobile
spec? I think it does what you want.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
Felix Meschberger <Fe...@day.com>
Sent by: Felix Meschberger <fm...@day.com>
2007-07-12 03:36
Please respond to
dev@felix.apache.org
To
Felix Dev <de...@felix.apache.org>
cc
Subject
Configuration Admin Extension
Hi all,
Currently the Felix Config Admin implements the spec and as such
provides the configuration objects as required. What we are missing here
in one our projects is some kind of default configuration.
As far as I understand the specs, the Configuration Admin provides
configuration to ManagedService[Factory] objects. In addition the
Declarative Services specification defines, that the declared components
must be provided with Configuration Admin configuration (if the service
and such configuration is available) overwriting any declared properties
in the component declarations.
Our issue now is, that in some cases the default configuration inside
the ManagedService[Factory] objects or the declared components are not
sufficient for the application but the Configuration Admin does not have
any configuration yet to overwrite the defaults. We came up with the
idea of supporting such initial configuration to the Configuration Admin
inside of deployed bundles. Some service would pick up this
configuration and add it to the Configuration Admin.
So here is, what I propose:
The ConfigurationManager of the Felix Config Admin listens for bundle
changes. Whenever a bundle is installed, a special bundle manifest
header - e.g. Felix-Configuration - would be read, which contains a
comma-separated list of bundle entries. Each entry contains one or more
configurations to be added to the Configuration Admin. The
configurations from the bundles would be added to the Configuration
Admin using the permissions of the bundle providing the configuration.
Configuration is only added. That is, for normal configurations
(non-factory), the configuration is only added if no configuration with
the given service.pid already exists. For Factory configuration, the
given configuraiton would only be added if no factory configuration for
the given service.pid already exists. (In the future support for
configuration update/enhancement might be added, but this is a wide open
field, which I would not want to touch yet).
What do you think ? Would such an extension make sense to other people ?
Is the conceptual approach correct ?
I will provide a prototype implementation shortly in a JIRA issue for
further consideration.
Thanks for any feedback on this.
Regards
Felix