directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ApacheDS] [XBeans] [Spring] Any issue with moving to spring 2.5?
Date Wed, 27 Aug 2008 00:20:30 GMT
On Tue, Aug 26, 2008 at 5:14 PM, Emmanuel Lecharny <>wrote:

> Hi Stefan,
> not only is this complex from the user POV, but from the developper POV,
> this is a nightmare. I frankly don't like those annotations stuff, plus the
> fact that the objects are instanciated during the xml file processing is a
> real burden (and makes the configuration file way too complex).
> I will talk my mind : I think that going for Spring was a big mistake.


> Now, what can we do ? I think that the way to go is to have the
> configuration in the DIT, with LDIF based configuration files (like OpenLdap
> has).
> The question is when will we have time to do that...

That's the big question.  I can do it fast if I had a few things in my tool
chest like an LDAP persistence engine.  But that in it self will take a
while to develop.

More inline on Stefan's comments ...

> Stefan Zoerner wrote:
>> Hi all,
>> regarding configuration with the server.xml file: The current solution is
>> still not perfect; it simplifies the file a lot, but some things are really
>> complicated to accomplish.
>> I have started to documented it in the Basic User's Guide, but I stopped,
>> because I still hope for some improvements before finalization in the 2.0
>> Providing a context entry for instance is definitely not acceptable for our
>> users.
>> This is a fragment of the current style (perhaps I have missed something):
>> ---
>>  <spring:bean id="systemContextEntry"
>>  class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>>    <spring:property name="targetObject"><spring:ref
>> local='directoryService'/></spring:property>
>>    <spring:property
>> name="targetMethod"><spring:value>newEntry</spring:value></spring:property>
>>    <spring:property name="arguments">
>>      <spring:list>
>>        <spring:value xmlns="">
>>          objectClass: top
>>          objectClass: organizationalUnit
>>          objectClass: extensibleObject
>>          ou: system
>>        </spring:value>
>>        <spring:value>ou=system</spring:value>
>>      </spring:list>
>>    </spring:property>
>>  </spring:bean>
>> ---
>> Note that also need a custom Editor for Attributes to be configured.
This can be partially avoided with custom registrars in Spring but no need
to go into that.  Still sucks to do.

>> Defining your own partition is at least hard with that. It is not possible
>> to leave the context entry out, it won't work (NPE).
>> Question: Is it possible to change the partition implementation that it
>> works without providing an initial context entry in the configuration? In
>> this case, the user has to add the "root entry" with a tool/LDIF load after
>> starting the server with a new partition the first time, but this seems
>> acceptable for me.
Yeah we can do that or we can infer some minimal partition context entry
from the suffix.  But I prefer your method since all sorts of complications
may emerge from "inferring" the minimal context entry.

>> The configuration would become much easier then.
Yeah good point.  This is what we should shoot for.  We just need someone to
research that.

>> Another thing I was thinking about was creating our own namespace like
>> described here:
>> as an alternative to xbean. We would reduce the dependencies, although I
>> agree that using xbean and its meta data in the javadoc is better than
>> foreign annotations in our own sources.
Yeah I'm thinking as long as we don't have CiDIT we might as well stick with
XBean Spring.  We can always remove it for 3.0 which hopefully should not
take as long as 2.0 did.

I'd love to try to do CiDIT right away but we need some serious help.  We
need at least 1-2 extra solid hands to accomplish this to be able to get a
2.0 out before the end of the year.  I was hoping that GSoC student could
knock out a minimal persistence engine by now so we can race ahead and
replace XBean Spring with CiDIT but that never materialized.


View raw message