Hello Felix, On Aug 12, 2013, at 7:52 AM, Felix Meschberger <[email protected]> wrote:
> Currently our Declarative Services implementation statically binds > configuration to the using bundle when such configuration is used to > configure a component. The intent was to follow the Configuration Admin > specification which also statically binds configuration to > ManagedService[Factory] when first supplying configuration which is not > previously bound. In fact, the spec calls this "dynamic binding" when you supply a configuration that will be bound to the first bundle that registers a MS[F] with that PID. If this is indeed what you're talking about then I don't really get the problem you're describing as the spec already states (4.3 compendium 104.4.2): "When this dynamically bound Bundle is subsequently uninstalled, configurations that are bound to this bundle must be released. That means that for such Configuration object’s the bundle location must be set to null again so it can be bound again to another bundle." > This mechanism works really nicely but has a problematic drawback: When the > "owning" bundle is uninstalled, configurations remain bound. If a new version > of the same bundle is installed later, configuration will thus not be > supplied because, presumably, the bundle will have a new bundle location and > thus does not own the configuration. > > I could imagine two solutions to this problem: > > (1) DS does not statically bind configuration any longer. So, if unbound > configuration is supplied to a component, it just remains unbound. In my > understanding, this bends on the semantics defined by the Configuration Admin > specification. > > (2) DS maintains a list of configurations which it has statically bound. On > Bundle UNINSTALLED events the location of the uninstalled bundle is matched > against the bindings of the configurations in the list and if such bindings > exists, it is removed again. In my understanding, this would be the correct > solution but is somewhat more complicated to implement. > > WDYT ? Just exploring the possible solutions: (3) make sure you always set the location for the bundle with the same value, even after a re-install (for example, deployment admin uses the BSN as the location, which nicely solves this problem) (4) if you target 4.3 you could look into "using" the multi-location feature (although that might be bending the spec a bit as well) Greetings, Marcel
