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
