You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@adobe.com> on 2013/08/12 07:52:19 UTC
[DS/SCR] Configuration Binding
Hi
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.
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 ?
Regards
Felix
Re: [DS/SCR] Configuration Binding
Posted by Felix Meschberger <fm...@adobe.com>.
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
> <ma...@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 <da...@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 <fm...@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 <fm...@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
>>>>>
>>>>
>>>
>>
Re: [DS/SCR] Configuration Binding
Posted by Julian Sedding <js...@gmail.com>.
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
<ma...@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 <da...@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 <fm...@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 <fm...@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
>>>>
>>>
>>
>
Re: [DS/SCR] Configuration Binding
Posted by Marcel Offermans <ma...@luminis.nl>.
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 <da...@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 <fm...@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 <fm...@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
>>>
>>
>
Re: [DS/SCR] Configuration Binding
Posted by David Jencks <da...@yahoo.com>.
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 <fm...@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 <fm...@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
>>
>
Re: [DS/SCR] Configuration Binding
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 12.08.2013 um 08:16 schrieb Marcel Offermans:
> Hello Felix,
>
> On Aug 12, 2013, at 7:52 AM, Felix Meschberger <fm...@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
>
Re: [DS/SCR] Configuration Binding
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Felix,
On Aug 12, 2013, at 7:52 AM, Felix Meschberger <fm...@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."
> 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