directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [ApacheDS] [CiDIT] Discussion
Date Wed, 18 Jul 2007 07:38:10 GMT
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 also think you are seriously underestimating the effort involved in  
storing fine grained configuration information in ldap without hand  
coding the translation between the data store and actually creating  
the objects.  It took at least 5 years to come up with jaxb, which  
finally seems to be a usable approach for xml.  jdo/jpa also has been  
under various kinds of development for at least 5 years. IIRC Ole  
said he could come up with a ldap - object mapping in a couple of  
weekends, but that was 6 months ago and he is still saying it will be  
done in a couple of weekends.  I may be wrong but with the number of  
technologies that he usually mentions I have a hard time believing  
his solution will be sufficiently lightweight.

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
-- 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  

I still think that editing the configuration in ldap is going to be a  
lot more unpleasant than in an xml file with a schema telling you  
what's legal.

Are the distinguishing features of config-in-dit of big importance to  
users (replicated configuration changes and configuration change  
history, IIUC)?

A couple more comments inline below...
david jencks

On Jul 17, 2007, at 9:16 PM, Alex Karasulu wrote:

> Hi Chris (you spring lover you :) ),
> More inline but not snipping much since it's all very relevant ...
> On 7/17/07, Chris Custine <> wrote:
> 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:
>> cidit.html
>> 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?

In jdo or jpa you run an enhancer on your persistence capable classes  
and it takes the starting pojo class and changes the bytecode to  
actually talk to the persistence framework so your objects are loaded  
correctly and modifications saved correctly.  What the enhanced  
bytecode does is moderately similar to a lot of the code in the "hand  
enhanced" persistence objects in my copy of triplesec.  I'm not all  
that familiar with jaxb, and its goals are much more modest than jdo/ 
jpa, but IIUC it manages to do xml<> object translation with just the  
aid of a whole lot of metadata.  Since you appear to want to be able  
to replicate single-property changes I think you'll need something  
more like jdo/jpa than jaxb.

> 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  :-)
> The point I was trying to make is that people will export the  
> server's configuration as LDIF with
> the CiDIT approach with pure LDAP entries that do not have XML in  
> it.  Then they can load it
> into another server.
> 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.
> Well another problem is tracking changes.  Don't forget that we  
> will have a change log and if
> we store things in XML blobs we will simply obscure what is  
> actually being changed.  It's going
> to take more code to figure out the exact changes made.
> 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.
> But the question still in my mind is whether or not this is the  
> right approach.  LDAP is
> ideal for storing configuration information.  Why are we resorting  
> to XML and not eating our
> own dog food.
> 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?
> Well we will defer the actual implementation but we still have to  
> keep an eye out to make sure
> that what we are doing today does not close any doors tomorrow.  I  
> don't want to be stuck in
> a perpetual state of stepping backwards every time we have to  
> introduce new features like this.
> 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,
> The problem with this is that you're still going to have some  
> grouping of settings no?  If the
> functional interface of a component is 3 methods and there are 10  
> properties for settings
> then those 3 methods are going to be obscured.  Composite classes  
> grouping these settings
> will surely emerge.  Then we are back to having beans again.

Can you provide a concrete example of what you are talking about  
here?  So far to me I can't imagine how removing the configuration  
objects could do anything but make the code simpler cleaner and much  
easier to understand.
> 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 relationship.
> Essentially I think we're going to have to do the same things to  
> get to this state.  We need to
> factor out the init code that uses these beans from various  
> components that configure subcomponents.
> How we expose the settings on the component interfaces is a minor  
> point: whether using a complex
> object as one setting property or having several setting  
> properties.  It makes no difference.
> 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.
> Hmmm loosing you here a bit.  You mean to say 'enabling' rather  
> than 'removing' here? I
> thought you want the container to handle the functional component  
> directly right?
> If we used Spring the way we should be using it, I think we can  
> have our cake, and eat most of it ;-)
> My problem is proposing Spring to do this. The container discussion  
> about which one
> to use should come after we have prepared the server to enable the  
> direct configuration
> of the functional components.
> Alex

View raw message