Neil,
Yes, your comments were very helpful.
I too thought we maybe pushing the envelope on the intention of the spec.
In regards to PIDs I agree where the spec (104.3) says "Pids must be
unique for each service." But are they truly 'globally' unique? What I
mean - Is there yet a concept (a concept of global) within OSGi R4 where
more than one runtime is a consideration? (Maybe only these Config
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
Right I was hung up on that 1..1 persistence. Thanks to you and BJ for
pointing it out.
Regarding your implementation I'm not really clear on what your bundle
does in relationship to what the Equinox Config Admin does. Can you
give me some more details? (I tried to navigate to the Equinox Config
Admin @
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.config
But got a 404 not found error.)
Well the implementation I am working with is being done as part of an
ApacheDS team effort. Enrique Rodriguez did the initial work and I
have taken over with clean up of the initial prototype. (BTW- We
certainly can use some additional help;-)
As far as multiple adapters go I've tried to set this up so we can plug
in different DAO backends. Right now we are using of course a JNDI based
one.
cheers,
John
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
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
