Hi, currently our OSGi installer is a one way solution: things are picked up by the providers (jcr, file etc.) and installed through the OSGi installer core. Whenever something is changed through the providers, the change is picked up.
Unfortunately, if something changes by any other way, e.g. through the web console, these changes are not reflected by the providers. For example if a configuration is provided from jcr and later on changed through the web console, the change is not saved in jcr again. Currently, the OSGi installer adds a special property with the provider location to the configuration. So we could use this, to detect such configuration changes. I think a provider should listen for configuration changes and handle all configurations which have the above mentioned property set with a url coming from exactly this provider. In the file case, the provider can directly write the configuration back to the file system. In the repository we have the more complicated /libs,/apps setup. And even /libs, /apps is just a configuration. The basic idea here is that things in /libs get never overwritten by user changes. So if a configuration from /libs/bla is changed it should be persisted at /apps/bla. If a configuration from /apps/bla is changed, it can directly persisted at the same location. So basially we can generalize this. With these additions we handle changing already provided configurations. But what do we do with configurations originally not provided through an installer provider, e.g. configurations being added later on through the web console? One solution would be to add a flag to each provider implementation if it should persist such configurations. If the flag is set, the file provider will just write it to the file system; the jcr provider will write it to the repository at /apps/xyz. In the same way we could handle removals of configurations for example through the web console. The provider listens for such changes and then removes the configuration from the persistent storage. WDYT? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
