Re: [OSGi] Configuration Admin Service

["John E. Conlon" <jc...@verticon.com>]

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

Re: [OSGi] Configuration Admin Service

["John E. Conlon" <jc...@verticon.com>]

On Tue, 2006-03-14 at 10:52 -0500, Enrique Rodriguez wrote:
> John E. Conlon wrote:
> > On Thu, 2005-12-29 at 11:31, Enrique Rodriguez wrote:
> > 
> >>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?
> 
> I figure you can check out and review the OSGi work on Directory 1.1 or 
> pitch in on the use of CM for what is currently in the XML config.  Or 
> help in moving CM, Prefs, and UA over to Felix.  They'll need an M2 
> update, basic dep updates (refactoring, renaming packages), and 
> eventually updates to be R4-compliant.  Also, not all of the 
> directory-backed CM store was implemented; I only did what I needed to 
> make directory work.  Patches here would be great.
> 
> > How will you provide for attributes that have multiple values, like
> > objectClasses?
> 

> While they are returned by JNDI, I believe CM will ignore them.  If this 
> is outside the scope of CM then there isn't much we can do.  Multiple 
> values in config is typically on one line which gets tokenized.  This is 
> how I would do a multi-value, for example Kerberos encryption types; put 
> them in the DIT as one long string.  Or now, that I think about it, they 
> could be multi-valued in the DIT and converted to one-line strings by 
> the CM and parsed by the receiving service?  WDYT?


After reviewing the spec I think that the CM is limited (broken?) in
this regard. Maybe I am wrong and they did it for some good reason but
it sure makes it difficult to map real dit multi-objectclass entries
like an inetOrgPerson to CM. (There is so much in the spec references
LDAP that I wonder why this is speced like this.)

This limitation also seems to cascade into the Meta Type service. Too
bad with the LDAP schema and JNDI I think we could have easily provided
dynamic ObjectClass Definitions for all entries IF the CM and MetaType
were speced different. (If wishes were fishes.) Maybe a question into
the osgi-dev@bundles.osgi.org 
mailing list is in order?

Back to your quesion - 

If they are multi-valued in the DIT and converted to one-line strings by
CM I think we could generate something useful in CM and keep the DIT
more DIT like. Perhaps we could even generate something in CM from
standard entries that have multiple attributes with the same name?

I'll have to look, but I wonder if the interaction between the CM and
the MetaType specs show that one way is better than the other? 

John 

Re: [OSGi] Configuration Admin Service

[Enrique Rodriguez <en...@gmail.com>]

John E. Conlon wrote:
> On Thu, 2005-12-29 at 11:31, Enrique Rodriguez wrote:
> 
>>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?

I figure you can check out and review the OSGi work on Directory 1.1 or 
pitch in on the use of CM for what is currently in the XML config.  Or 
help in moving CM, Prefs, and UA over to Felix.  They'll need an M2 
update, basic dep updates (refactoring, renaming packages), and 
eventually updates to be R4-compliant.  Also, not all of the 
directory-backed CM store was implemented; I only did what I needed to 
make directory work.  Patches here would be great.

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

While they are returned by JNDI, I believe CM will ignore them.  If this 
is outside the scope of CM then there isn't much we can do.  Multiple 
values in config is typically on one line which gets tokenized.  This is 
how I would do a multi-value, for example Kerberos encryption types; put 
them in the DIT as one long string.  Or now, that I think about it, they 
could be multi-valued in the DIT and converted to one-line strings by 
the CM and parsed by the receiving service?  WDYT?

Enrique