Felix Meschberger <[EMAIL PROTECTED]> 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
