A PID is "globally" unique for a framework runtime. PIDs are usually
hard coded in bundles so it would be very hard to make them truly
globally unique and still know them on the management site.
I am not sure why you think you're pushing the spec? Central backends
have always been in the design?
Kind regards,
Peter Kriens
JEC> Neil,
JEC> Yes, your comments were very helpful.
JEC> I too thought we maybe pushing the envelope on the intention of the spec.
JEC> In regards to PIDs I agree where the spec (104.3) says "Pids must be
JEC> unique for each service." But are they truly 'globally' unique? What I
JEC> mean - Is there yet a concept (a concept of global) within OSGi R4 where
JEC> more than one runtime is a consideration? (Maybe only these Config
JEC> Admin issues we are now discussing are touching on this?)
>> However I think
>> the mistake you are making is assuming that there needs to be a one-to-one
>> correspondence between Configuration objects and your external storage of
>> those, i.e. in LDAP or whatever
JEC> Right I was hung up on that 1..1 persistence. Thanks to you and BJ for
JEC> pointing it out.
JEC> Regarding your implementation I'm not really clear on what your bundle
JEC> does in relationship to what the Equinox Config Admin does. Can you
JEC> give me some more details? (I tried to navigate to the Equinox Config
JEC> Admin @
JEC> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.config
JEC> But got a 404 not found error.)
JEC> Well the implementation I am working with is being done as part of an
JEC> ApacheDS team effort. Enrique Rodriguez did the initial work and I
JEC> have taken over with clean up of the initial prototype. (BTW- We
JEC> certainly can use some additional help;-)
JEC> As far as multiple adapters go I've tried to set this up so we can plug
JEC> in different DAO backends. Right now we are using of course a JNDI based
JEC> one.
JEC> cheers,
JEC> John
JEC> Neil Bartlett wrote:
>> John,
>>
>> I believe that what you say is technically correct, but you may be using
>> Config Admin in a way that it was not designed to be used.
>>
>> It's true that there is a one-to-one mapping of Configuration objects to
>> services. (NB in your third paragraph you suggest a second bundle that
>> registers a service with the same PID as another service. PIDs are meant
>> to be globally unique, so you shouldn't do this anyway). However I think
>> the mistake you are making is assuming that there needs to be a one-to-one
>> correspondence between Configuration objects and your external storage of
>> those, i.e. in LDAP or whatever.
>>
>> I am using Config Admin with external configuration stored in flat files
>> (actually JSON format but that's unimportant). The key point is there is a
>> one-to-many mapping between configuration "records" stored in the
>> filesystem and Configuration objects managed by Config Admin. The Config
>> Admin objects are also persisted by the Config Admin implementation (I'm
>> using the one supplied with Equinox, developed by Simon Kaegi) but I
>> regard that as an internal implementation detail of the Config Admin
>> service. I have my own bundle that is responsible for loading the external
>> config files and keeping them in sync with Config Admin.
>>
>> I know this involves some extra coding to map the same concept onto your
>> requirements. In my opinion it would be a great to have a little open
>> source project with a few of the most commonly-needed "adaptors" in there,
>> eg for XML files, LDAP, RDBMS, etc). I would contribute JSON adaptor I'm
>> using, but unfortunately the copywrite is not owned by me.
>>
>> I hope this helps. Regards,
>> Neil
>>
>>
>>
>>> Your right when the Configuration object is created it can be bound to a
>>>
>> bundleLocation or not (left null). But when a Configuration Target
>> (ManagedService or ManagedServiceFactory) registers and the
>>
>>> bundleLocation of its matched configuration is found to be null. (ie
>>>
>> not bound) Then its bundleLocation is bound dynamically to the
>>
>>> configuration.
>>>
>>> 104.12.3 says: "In this scenario the Configuration Object must become
>>>
>> bound to the first bundle that registers a ManageService (or
>>
>>> ManagedServiceFactory) with the right PID."
>>>
>>> If a second bundle in the same or a different OSGi runtime tries to
>>>
>> register a bundle that also utilizes the same configuration data (same
>> ServicePID) 'an error should be logged and that the registering bundle
>> should only be given a null'.
>>
>>> 104.4.1 : "If a Managed Service is registered with a PID that is already
>>>
>> bound to another location, the normal callback to ManagedService.updated
>> must not take place."
>>
>>> On the other hand this binding is set to null when the bundle is
>>>
>> unregistered from the runtime, but this still limits the configuration
>> to a one at a time binding.
>>
>>> So if I have a enterprise directory server that I wish to use to serve
>>>
>> up configurations to OSGi applications throughout the enterprise. I
>> will not be able to have more than one bundle registering and bound to
>> each configuration. Effectively limiting the enterprise directory to
>> service one application instance at a time. If I needed N number of
>> instances of an application deployed through out an enterprise I would
>> need a number of configurations on the directory server equal to the
>> number of expected concurrent configuration targets. In other words
>> ConfigurationAdmin is constrained to a 1..1 relationship of concurrent
>> configuration targets to persisted configurations.
>>
>>> Perhaps I am overlooking a workaround somewhere?
>>>
>>> cheers,
>>>
>>> John
>>>
>>>
>>>
>>> Peter Kriens wrote:
>>>
>>>> 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
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> [email protected]
>>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
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
