First the location binding is option, if it is set to null, it no
longer plays a role.
I am not sure I can follow your logic. Could you give a concrete use
case that seems impossible to you? I do not think a backend is in any
way constrained.
Kind regards,
Peter Kriens
JEC> Section 104.15.2.8 of the R4 for Configuration Admin, specifies that
JEC> bundle locations can be be bound at configuration creation time to
JEC> persisted Configuration entities. Does 'bound' mean that this value
JEC> should be persisted along with the configuration data?
JEC> Section 104.4.1 specifies how Configuration Target bundles should be
JEC> bound dynamically on registration to Configuration objects.
JEC> These location binding requirements seem to constrain the Configuration
JEC> Admin to offer only a 1..1 relationship between a persisted
JEC> configuration entity and a single configuration target instance. As I
JEC> understand it the spec also seem to rule out the use case where an
JEC> organization wishes to use a common Enterprise Store as a central
JEC> configuration repository for persisted entities serving N number of
JEC> configuration targets on multiple osgi runtimes. (1..n relationship
JEC> between persisted entities and configuration targets.)
JEC> Is this the intention? If so, how could the 1..n use case I describe be
JEC> accomplished?
JEC> thanks for any clarification,
JEC> John Conlon
JEC> Verticon, Inc.
JEC> _______________________________________________
JEC> OSGi Developer Mail List
JEC> [email protected]
JEC> http://www2.osgi.org/mailman/listinfo/osgi-dev
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
