directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: [OSGi] Configuration Admin Service
Date Thu, 29 Dec 2005 17:31:44 GMT
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.


View raw message