I don't think you're missing something. The spec states CA should be doing that already, so if our implementation is not, we should raise a bug.
Greetings, Marcel On Aug 12, 2013, at 9:40 , David Jencks <david_jen...@yahoo.com> wrote: > 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 <fmesc...@adobe.com> wrote: > >> Hi >> >> Am 12.08.2013 um 08:16 schrieb Marcel Offermans: >> >>> Hello Felix, >>> >>> On Aug 12, 2013, at 7:52 AM, Felix Meschberger <fmesc...@adobe.com> 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 >>> >> >
