directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: [ApacheDS] [CiDIT] Discussion
Date Wed, 18 Jul 2007 16:59:22 GMT
On 7/18/07, Chris Custine <> wrote:
> 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:
> <SNIP>
> 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.

That was also my point in an initial discussion on the topic. We need to add
an LdapBeanDefinitionReader to the following list:

-- 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.
> >
> >
> <SNIP>
>  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 this 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
> work.

Ersin Er

R.A. and Ph.D Student at the Dept. of Computer Eng. in Hacettepe University

Committer and PMC Member of The Apache Directory Project

View raw message