directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <ccust...@apache.org>
Subject Re: [ApacheDS] [CiDIT] Discussion
Date Wed, 18 Jul 2007 17:21:48 GMT
I think Alex's main concern is to not trap ourselves into depending on
Spring for all use cases (full server, embedded, unit test kit, etc.).  I
think simplifying the config by moving configuration bean properties to the
actual beans is a step in the right direction because then anything can wire
up the services.  Further refactoring the initialization so that it isn't
spread around all over is another step.  In the end, all of these things
will allow us to be fairly agnostic WRT the container and the components
will be standalone pieces that need to be instantiated and wired together by
any means, whether it is Spring or not.

Once we get to this point, I think it will be easier to choose the preferred
container, especially for the stand alone server installation.  Hopefully we
can also maintain the more bare bones nature of the embedded use case as
well, without requiring a container.  To be quite honest, I am hoping we can
refactor the configuration and startup layer such that CiDIT, Spring, OSGi,
etc. are choices that the user/integrator can make on their own if possible.

Chris

On 7/18/07, Ersin Er <ersin.er@gmail.com> wrote:
>
>
>
> On 7/18/07, Chris Custine <ccustine@apache.org> 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 < david_jencks@yahoo.com> 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:
> http://www.springframework.org/docs/api/org/springframework/beans/factory/support/BeanDefinitionReader.html
>
> -- 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
> http://www.cs.hacettepe.edu.tr
>
> Committer and PMC Member of The Apache Directory Project
> http://directory.apache.org
>

Mime
View raw message