directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <>
Subject Re: [ApacheDS] [CiDIT] Discussion
Date Wed, 18 Jul 2007 16:52:48 GMT
For what its worth, I think we are all actually talking about the same thing
here, but we have divergent opinions on the implementation.  These are good
discussions and hopefully they will bring clarity and consensus.

Just a couple of comments inline below...

On 7/18/07, David Jencks <> wrote:

So I think that the idea of making the components container agnostic is a
> great idea and I think the best way to do that is to start by removing the
> configuration objects and dealing directly with the functional components,
> as Chris and I have been suggesting.I think you are also seriously
> underestimating the difficulty of writing a usable container framework.
>  AFAIK Spring doesn't do too much except act as a wiring framework, but at
> least it works and is well understood.  IIUC it does not really do
> dependency management which I think is required for changing configuration
> without restarting the entire server on any change.  When I looked at OSGI
> it had a nice classloader and a big spec, but I couldn't find a wiring
> framework or component model or component dependency management.  (I'm sure
> I missed a lot of OSGI).  Geronimo makes you describe the component metadata
> in a rather inconvenient java form although it has a wiring framework and
> dependency management.
> I think a reasonable path to follow would be to:
> -- stop abusing spring, i.e. remove the configuration objects and make the
> functional objects container agnostic.
> -- consider xbean-spring to make type-checked configuration files

Another step here would be to write some Spring extensions (extend
AbstractApplicationContext, et al) to load our bean definitions from an LDAP
schema.  I have written code that extends Spring to read bean definitions
from JDBC and other sources that aren't built in to Spring and it works just
fine.  This way we can store custom config in a schema, but still use all of
the DI framework, etc.

-- do some experiments to see about ldap <> component mappings.  Maybe Ole's
> system will be lightweight enough to be used for server startup.  Maybe you
> can write something else that works and is easy to extend to new
> components.
> -- if those experiments succeed, try storing the configuration in the dit.

Someone suggested a while back that we avoid the "jdo for ldap" problem by
> > > > just storing server.xml in ldap as text.  IIUC this could be done in
> > > > a couple of days.  Exactly how much really useful functionality would
> > > > lose compared to the fine grained approach?
> > > >
> > >
Maybe this could be an incremental part of this overall task.  I think it
will also help us refine the approach as we go along without doing too much

View raw message