Hi Thanks for the discussions.
To wrap this up: turns out I was wrong and so I fixed the issue as part of FELIX-3360 in the Configuration Admin service implementation. Regards Felix Am 12.08.2013 um 10:39 schrieb Julian Sedding: > 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 > <[email protected]> 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 <[email protected]> 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 <[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 >>>>> >>>> >>> >>
