directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: [OSGi] Configuration Admin Service
Date Wed, 15 Mar 2006 03:22:09 GMT
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 


Mime
View raw message