See FELIX-3360, where I raised the same issue and provided a patch. The patch may be outdated by now, I didn't check recently.
Regards Julian [0] https://issues.apache.org/jira/browse/FELIX-3360 On Mon, Aug 12, 2013 at 9:42 AM, Marcel Offermans <marcel.offerm...@luminis.nl> wrote: > 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 >>>> >>> >> >
