I briefly discussed this with Felix here at ApacheCon :) and we think that we should have some kind of callback mechanism from the core installer to the providers whenever configurations change etc.
So, basically it's the OSGi installer core listening for all configuration changes. A provider who is interested in changes, registers a callback service. This service is registered with a property specifying the provider id (which is the url scheme). So for example jcrinstall uses the value "jcrinstall". The callback is notified for config changes and config removals. If there is more than one callback service with the same id, we use the service ranking. If a callback service is registered with an additional service property "default-handler" (maybe we'll use a different value here), it gets notified when new configurations are added. This is the provider used for new configurations that originally did not come from a provider. Regards Carsten Carsten Ziegeler wrote > 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
