You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "John E. Conlon" <jc...@verticon.com> on 2005/12/14 17:16:57 UTC
[OSGi] Configuration Admin Service
Currently I am using ApacheDS and 'typical' LDAP schemas to persist my
business objects. These objects are Locations (objectClass=locality),
People (objectClass=person), and mobile Devices (objectClass=device).
On startup my application uses a JNDI DirContext to search a directory
at a specified base for all the above objectClasses that also contain a
labeledURI attribute and load my business model.
Am looking to move away from the JNDI dependence to the ApacheDS based
OSGi Configuration Admin service.
Will I be able to continue to use these business 'typical' LDAP schema
objectClasses and search filters with the ApacheDS/OSGi Configuration
Admin Service to search, load and persist my business objects?
thanks,
John
.
Re: [OSGi] Configuration Admin Service
Posted by Enrique Rodriguez <en...@gmail.com>.
Enrique Rodriguez wrote:
> ... Changes to the stored port in the DIT generate events via
> the JNDI EventDirContext which the Config Admin service is listening to,
> and the Config Admin service tells the Kerberos factory to destroy
> and/or create instances of the Kerberos service.
This last part isn't totally accurate. The Config Admin service blindly
passes the configuration attributes to the Kerberos factory, and the
Kerberos factory is written in such a way as to figure out based on the
incoming configuration whether to create and/or destroy instances of the
Kerberos service.
Enrique
Re: [OSGi] Configuration Admin Service
Posted by "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
Posted by 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
Re: [OSGi] Configuration Admin Service
Posted by "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
Posted by Enrique Rodriguez <en...@gmail.com>.
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.
Enrique
Re: [OSGi] Configuration Admin Service
Posted by Enrique Rodriguez <en...@gmail.com>.
John E. Conlon wrote:
> Hi Enrique,
>
> Knew you where at the conference so I expected a delayed response. Hope
> the conferences sessions and bofs were recorded so we can all see/hear
> more details one of these days.
IIRC, the conference promoters were pre-selling the multimedia for
ApacheCon at $349. I briefly Googled but couldn't find a link. As with
Trustin, I'll make my PDF prezo available online.
>>At first glance your use case doesn't look like it fits with Config
>>Admin. Config Admin is not for generic business object operations.
>>Rather, the typical Config Admin use case is design to "inject"
>>configuration information into components.
>
> The R4 Configuration Admin spec for ManagedServiceFactory and the
> examples in the Service Compendium sure looked like it would fit my
> requirement for modeling the business objects configured from LDAP
> objectClasses. BTW my objects do exist within a single Service component
> and they may in the future grow up to be registered services themselves
> one day;-)
I think I see where you are coming from:
1) You have a Person objectClass which is essentially name-value pairs
in the form of LDAP attributes. You wish to create a Person Java object.
2) The ApacheDS Config Admin service listens to a node in the DIT
designated for configuration (ou=configuration,ou=system) and upon
creation or changes to configuration objectClass'es in the subtree below
said node, will pass a dictionary of attributes formerly contained in
the configuration objectClass to any ManagedService(Factory) registered
under a service PID that matches the service PID of the configuration in
the DIT.
3) A ManagedService(Factory) is free to do whatever it wants with the
configuration attributes "injected" into it by the Config Admin service.
You could write a factory that produces Person objects.
While you could use the Config Admin service this way, I believe it
would be a misuse of the Config Admin service. But, honestly, I can't
come up with better reasons than intended use and bloat: (a) Config
Admin is intended for configuring bundles, aka services and (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.
If my understanding, above, is correct, what you really want is to use
standard JNDI:
1) In order to convert objectClasses into Java objects JNDI provides
the concept of the object factory:
http://java.sun.com/products/jndi/tutorial/objects/factory/index.html
2) If you want to react dynamically to changes to the underlying
objectClasses you can register listeners by casting CoreContextFactory
to EventDirContext. The EventObject's returned by the listener will
contain the before and after attributes of changed nodes.
http://java.sun.com/products/jndi/tutorial/beyond/event/index.html
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.
The JNDI Object Factory's do have some limitations, such as the
difficulty of providing initial and/or default values during object
creation, which I why I don't use them in the Config Admin service -
Config Admin requires the returned dictionary to contain attributes
calculated by the Config Admin service and a JNDI Object Factory would
return a complete object.
Enrique
Re: [OSGi] Configuration Admin Service
Posted by "John E. Conlon" <jc...@verticon.com>.
Hi Enrique,
Knew you where at the conference so I expected a delayed response. Hope
the conferences sessions and bofs were recorded so we can all see/hear
more details one of these days.
> At first glance your use case doesn't look like it fits with Config
> Admin. Config Admin is not for generic business object operations.
> Rather, the typical Config Admin use case is design to "inject"
> configuration information into components.
The R4 Configuration Admin spec for ManagedServiceFactory and the
examples in the Service Compendium sure looked like it would fit my
requirement for modeling the business objects configured from LDAP
objectClasses. BTW my objects do exist within a single Service component
and they may in the future grow up to be registered services themselves
one day;-)
Even hoped to leverage directory metadata in conjunction with the
MetaType service. Along these lines I also noticed that the R4 Service
Compendium MetaType service (page 140-432) even gives an example using a
person objectClass (OID 2.5.6.6).
I looked at your sandbox configuration implementation and saw that you
are using an InitialContextFactory as an OSGi bundle service for the
ConfigurationAdminFactory. Would this InitialContextFactory be a more
appropriate service for me to depended on (at least in the short term)
and just keep my JNDI access as is?
welcome back,
John
Re: [OSGi] Configuration Admin Service
Posted by Enrique Rodriguez <en...@gmail.com>.
John E. Conlon wrote:
> Currently I am using ApacheDS and 'typical' LDAP schemas to persist my
> business objects. These objects are Locations (objectClass=locality),
> People (objectClass=person), and mobile Devices (objectClass=device).
>
> On startup my application uses a JNDI DirContext to search a directory
> at a specified base for all the above objectClasses that also contain a
> labeledURI attribute and load my business model.
>
> Am looking to move away from the JNDI dependence to the ApacheDS based
> OSGi Configuration Admin service.
>
> Will I be able to continue to use these business 'typical' LDAP schema
> objectClasses and search filters with the ApacheDS/OSGi Configuration
> Admin Service to search, load and persist my business objects?
Hi, John,
I'm just getting to your question after an extended stay in CA for
ApacheCon.
At first glance your use case doesn't look like it fits with Config
Admin. Config Admin is not for generic business object operations.
Rather, the typical Config Admin use case is design to "inject"
configuration information into components. The common use in ApacheDS
is to store what are now properties in the Spring XML as attributes in
schema for the protocol providers. For example, an IP port for Kerberos
to listen on can be stored as attribute ipPort=88. When a factory for
Kerberos servers is started, the factory identifies itself to the Config
Admin service, which in turn tells the Kerberos factory what ports to
listen on. Changes to the stored port in the DIT generate events via
the JNDI EventDirContext which the Config Admin service is listening to,
and the Config Admin service tells the Kerberos factory to destroy
and/or create instances of the Kerberos service.
Enrique