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 jndi.properties 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 released. > > >>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 objectClasses? John
