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 03:36:26 GMT
On 7/17/07, Alex Karasulu <> wrote:
> Hi David,
> On 7/17/07, David Jencks <> wrote:
> >
> >
> > On Jul 15, 2007, at 8:03 PM, Alex Karasulu wrote:
> >
> > Hi all,
> >
> > Here's that thread on discussing the CiDIT agenda. Let's take a look at
> > the following
> > link before beginning:
> >
> >
> >
> >
> > Thoughts? Comments?
> >
> >
> > Yikes, I'm afraid this will take 6 months to a year to do, and unless
> > you write "jdo for ldap", including an enhancer, I think its' going to be
> > pretty painful to add new configuration elements.
> >
> Yes it would take considerable time if we did it by hand. I think we can
> avoid this with a solid persistence mechanism for LDAP which also generates
> the LDAP schema from bean interfaces.
> What is this enhancer you talk about above?
> 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?
> >
> This has a few issues but the most important one is that I want eventually
> to replicate
> the configuration within a cluster.  Yes this would still be possible but
> I don't want to
> replicate the entire configuration ... just the parts of it that should be
> shared across the
> cluster.  With a blob in the DIT you have to replicate the whole thing.
> Another issue is with LDIF exports of the blob.  I like the idea of
> dumping the configuration and then importing it perhaps with changes.  This
> becomes more of a problem with a big XML blob.  Hand exiting an XML embedded
> within an LDIF is a PITA.

So lets not do it  :-)  I don't like the idea of editing LDIF to affect
configuration changes on the server.  If we store the XML (or snippets)
directly, we don't need the LDIF and we can bypass it.  I have a lot of
notes that I will post about how we can do this very easily without a lot of
demolition of current code.

The whole attribute value with the XML blob must be replaced for even the
> simplest changes to the configuration.  You also cannot easily determine
> exactly what changed to notify the component corresponding to the
> configuration object that changed.

I'm not sure how plausible this is until we go to OSGi so maybe we should
defer that goal anyway?

You cannot easily search and modify configurations through simple LDAP
> clients.
> This is a hack.
> What if each component/bean configuration were stored as xml text
> > separately, each with a (unique) name, and the links were determined by the
> > names?
> >
> Sure that could be done as well but why not just bang it out if you're
> going to wrestle with
> all this anyway.
> BTW, unless you write a fancy dependency tracking system ( i.e. the
> > geronimo kernel) I think that any change basically requires stopping and
> > restarting the server, so I'm not sure there is really much advantage to
> > splitting up each bean separately.
> >
> The dynamic reconfiguration capabilities will be reserved until we do have
> such a system: OSGi based most likely.
> And finally, why are there all these configuration objects that spring
> > creates that then go and create the actual runtime objects, rather than
> > having spring create the runtime object directly?  In particular, why is
> > there an interceptor configuration object rather than just interceptors?
> >
> They were there since the beginning.  I have no idea why they were put
> there.  What I do know is that I want to get Spring out of the picture and
> make this server container agnostic.  Then we can wrap it up in any kind of
> container we like.

A point that I have been trying to make is that if we remove the
configuration beans and let the components contain their own settings, that
is achieving container independence too, and that is the way it should be.
At that point, ANY framework can configure the components, whether it is
Spring, OSGi, Java instantiation, etc.  I really think the configuration
beans are the root of all evil in this discussion and it seems like we keep
coming back to them as either the cause or symptom of something.  So lets
toss 'em and configure the components so that we can keep a 1:1

Are you finding that Spring has some limitations that you are running into?
> > Otherwise why eliminate it?
> >
> Same reason I keep OSGi out of the core or why I stripped out Avalonisms.
> Let's stay container agnostic.

Well, as I said above, the configuration beans and removing the ability to
directly configure the functional components directly seem to be the
limiting factor to me.  If we used Spring the way we should be using it, I
think we can have our cake, and eat most of it ;-)


View raw message