Yes, we likely should review and update the spec to make that clear if it is not. I just realized that I ran into my other question while implementing CM and running it against the CT. The CT does enforce a rule for unbound configurations becoming bound to new targets if they exist.
Tom From: Felix Meschberger <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 08/14/2013 12:03 AM Subject: Re: [osgi-dev] [CM] Static vs. dynamic Location Binding Sent by: [email protected] Hi Tom Am 13.08.2013 um 15:45 schrieb Thomas Watson: Felix, I agree, and I think 'implicit' binding is a better term than 'dynamic' binding. Any time a bundle is uninstalled which has implicitly bound configurations must result in the implicitly bound configurations becoming unbound. Should we add a clarification to the spec ? My follow up question is: What happens if another MS exists for the newly unbound PID? Does the CM implementation then call MS.update for the configuration and implicitly bind it to another bundle? Yes, that's what's actually happening and is required since CM 1.4 (Compendium R4.3) in the "If a target loses visibility " paragraph of section 104.4.1. Up to and including CM 1.3 (Compendium R4.2) this was not the case. Regards Felix Thanks. Tom <graycol.gif>Felix Meschberger ---08/13/2013 08:20:20 AM---Hi Thanks for the feedback. From: Felix Meschberger <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 08/13/2013 08:20 AM Subject: Re: [osgi-dev] [CM] Static vs. dynamic Location Binding Sent by: [email protected] Hi Thanks for the feedback. So, to summarize: (A) static binding: * getConfiguration(pid, location) where location != null and configuration is created * createFactoryConfiguration(factoryPid, location) where location!= null * Configuration.setBundleLocation(location) where location != null (b) dynamic binding: * supply configuration to ManagedService[Factory] if location was null * getConfiguration(pid) where configuration location was null before or configuration is created * createFactoryConfiguration(pid) In other words: all (implicit) bindings not explicitly declared with a location parameter to a method call are dynamic. Regards Felix Am 12.08.2013 um 16:46 schrieb Thomas Watson: I agree, that is what I was trying to say with case 1). But you seem to be saying that it gets (dynamically) bound to the calling bundle regardless of what the current value of the location is. I disagree. It can only get (dynamically) bound to the caller if the current location is null. Tom <graycol.gif>Marcel Offermans ---08/12/2013 09:27:54 AM---I am pretty sure that if, as a consumer, you create a configuration with getConfiguration(pidX), it From: Marcel Offermans <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 08/12/2013 09:27 AM Subject: Re: [osgi-dev] [CM] Static vs. dynamic Location Binding Sent by: [email protected] I am pretty sure that if, as a consumer, you create a configuration with getConfiguration(pidX), it gets bound to you. Otherwise, why would getConfiguration(pidX, null) even exist? On Aug 12, 2013, at 14:46 , Thomas Watson <[email protected]> wrote: There are two cases where a location is bound 'dynamically'. 1) A bundle calls ConfigurationAdmin.getConfiguration (pidX) and a new configuration is created (i.e. no existing configuration exists). In this case it gets dynamically bound to the calling bundle. 2) A configuration exists with pidX with a null location. A) a bundle calls ConfigurationAdmin.getConfiguration (pidX), calling bundle gets bound or B) a ManagedService is registered with pidX, the registering bundle gets bound. The only way to have a 'statically' bound configuration is when a management agent uses ConfigurationAdmin.getConfiguration(pidX, location) where location != null. All other situations will be dynamically bound and should result in the configuration getting unbound when the bound bundle is uninstalled. To me that makes the most sense and is the most simple explanation. Tom <graycol.gif>Marcel Offermans ---08/12/2013 06:14:40 AM---On Aug 12, 2013, at 13:02 , Felix Meschberger < [email protected]> wrote: > Somehow this comes up ev From: Marcel Offermans <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 08/12/2013 06:14 AM Subject: Re: [osgi-dev] [CM] Static vs. dynamic Location Binding Sent by: [email protected] On Aug 12, 2013, at 13:02 , Felix Meschberger < [email protected]> wrote: > Somehow this comes up every now and then and I am always lost finding the definitive answer ... > > Situation A > - Configuration created with getConfiguration(pidA, null) > - ConfigurationAdmin supplies to ManagedService MSA > > Situation B > - Configuration created with getConfiguration(pidB, null) > - consumer calls ConfigurationAdmin.getConfiguration (pidB) > > Situation C > - Configuration created with getConfiguration(pidC) > > IIUIC Situation A creates a dynamic location binding to MSA's bundle. When the bundle is uninstalled, the location is reset to null. > > In Situation C, the location binding is static to the caller's bundle location. > > What about Situation B: On the one hand, the same API is used as in Situation C. Thus one might argue, this results in a static binding to the caller's bundle. On the other hand, one might argue, that this binding is dynamically set upon the first time it is used by a bundle. > > What is the correct answer in Situation B ? Static or Dynamic ? Location binding only applies when a configuration object is *created* in response to someone calling getConfiguration (or getFactoryConfiguration), so in B: - the first all makes it dynamic - the second call binds it to the consumer At least, that's my interpretation. :) Greetings, Marcel _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
<<inline: graycol.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
