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





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

<<inline: graycol.gif>>

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to