directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <>
Subject Re: [OSGi] Configuration Admin Service
Date Mon, 02 Jan 2006 16:27:24 GMT
On Thu, 2005-12-29 at 11:31, Enrique Rodriguez wrote:
> 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.
How can I help? 

> ...
> > 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.
I assumed that ICF would be a good bundle service. For now I am using within a ICF service bundle to access an external
ApacheDS. I expect it to be easy to plug in the OSGi ApacheDS when it is
> >>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.

How will you provide for attributes that have multiple values, like


View raw message