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 [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Felix Meschberger <[EMAIL PROTECTED]> Sent by: Felix Meschberger <[EMAIL PROTECTED]> 2007-07-12 03:36 Please respond to dev@felix.apache.org To Felix Dev <dev@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
