Hi, I was under the impression that setting the location of the configuration to null when the bundle that owns the configuration is uninstalled was the responsibility of config admin. Config admin sets the location when you call getConfiguration using the bundle's CA, surely it is also CA's responsibility to track the bundle and undo the locations when the bundle is uninstalled.
Am I missing something? I don't see how it could affect this but I have a few tests and bug fixes for location binding and targeted pids that I hope to finish up and commit in the next couple of days. thanks david jencks On Aug 12, 2013, at 12:34 AM, Felix Meschberger <[email protected]> wrote: > Hi > > Am 12.08.2013 um 08:16 schrieb Marcel Offermans: > >> 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." > > Yes, that would be my solution (2) ;-) >> >>> 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) > > You can only set the location from Bundle.getLocation() and DS has no > influence on that. Other installers may use the actual source URL from which > the bundle was installed. > >> >> (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) > > Right. That's a thread for the Web Console for example: If configuration is > created with the Web Console it should use the generic "?*" location by > default if the appropriate Configuration Admin API is wired. > > Regards > Felix > >> >> Greetings, Marcel >> >
