John E. Conlon wrote:
On Tue, 2005-12-20 at 16:38, Enrique Rodriguez wrote:
...
My bundle is offering a service to other bundles and it is being
configured by adding people locations and devices. I may be dense (my
wife thinks so) but I don't understand why I would not be conforming
with the use case here. I am also thinking that these JavaObjects may
really be candidates for finer grain services in there own right. (for
example A location object as a service that could notify other bundles
of events related to it.)
You know your use case best.
(b) you are
also adding a dep on Config Admin and Config Admin does include other
functions such as an administrative interface for manipulating
configuration information.
I may gain a dep on Config Admin but it reduces maintenance because I
throw away my current loading infrastructure. The other point you
mention is also a plus as I was looking for a integrated environment for
manipulating configuration. (Right now recommending a standalone LDAP
editor.)
Great. Again, I don't know your use case. BTW, the config admin
service isn't totally done: not all of the store ops work. I'd love
some help here; their impl should be straightforward, I just have only
done the ones I need.
...
Speaking of ContextFactories, looked at your sandbox configuration
metadata.xml file and saw that javax.naming.spi.InitialContextFactory
was a required service. Is javax.naming.spi.InitialContextFactory (or
will it) be a OSGi service offered by the ApacheDS bundle?
The standalone-osgi wrapper for apacheds registers the ICF as a service.
The protocol-providers currently depend on ICF but as we progress I
expect to decompose the protocol-providers into protocol workflow and
protocol store bundles, the protocol store depending on ICF.
That said, you do bring up an interesting point, that once you start
coding with EventDirContext you'll write half of what the ApacheDS
Config Admin service does ... in which case there is likely a use case
and thus reason to break the ApacheDS Config Admin service into finer
components, one of which is an EventDirContext-to-Object component.
ApacheDS' Config Admin could use said component to listen for
Configuration objects and you could use it to listen for Person objects.
Would probably use it to listen for changes to all labledURIObjects
because will be using the URI as the PID. Now here the difficult issue
comes in about how to handle entries that have multiple objectclasses.
Would all the attributes be included when updated is called? If that is
too sticky there is always the ConfigurationPlugin to get the rest of
the attributes directly from the directory, which would require the JNDI
dependency in the bundle.
I think for know we'll pass along all attributes. We can learn if there
is something to do better with CM plugins.
Enrique
