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
