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
