directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Ldif loader move ?
Date Mon, 17 Mar 2008 16:21:23 GMT
David Jencks wrote:
> On Mar 17, 2008, at 2:09 AM, Emmanuel Lecharny wrote:
>> Hi,
>> while checking the configuration, I saw that the LdifLoader methods 
>> (ldif files can be loaded during the startup sequence) belong to the 
>> ApacheDS class. I think they are more likely to belong to 
>> DirectoryService, so I just want to know if there is any kind of 
>> objection if I move the related code to this class.
> My comments are based on my recollection that ApacheDS is the "top 
> level" class that coordinates the protocol components and the engine, 
> and DirectoryService is the engine.  If I'm wrong.... tell me.
No, from the top of my head, I would say you are right.
> I don't think that loading ldif files is a core engine function, so I 
> really don't think methods relatiing to it should be attached to the 
> core engine.  Since IIRC ApacheDS is more like "coordination glue" it 
> seems to me that given the choice it is a better place.
Well, thinking twice about it, you may be right about the fact that 
loading ldif files should not be attached to the core engine. Maybe the 
DirectoryService class is the place to deal with ldif loading ? On the 
other side, I would keep ApacheDS as simple as possible.
> However I think perhaps an entirely separate component that has a 
> reference to DirectoryService and knows about the files to load might 
> be an even better solution?  Also isn't there some code duplication on 
> this functionality between the server and studio?  
Yes and no. There are two things in this functionality :
- it injects some entries in the server
- it also stores the loaded ldif file name into the server

The idea is to load the file only once, when you setup the server the 
very first time.

Studio is just a tool which can inject some entries into the server, no 
matter if those entries are stored into a LDIF file or not. Anyway, in 
both cases, the LDIF file is read, and transformed to JNDI calls. This 
is where we might ave a big difference in 2.0 (or later version) : if we 
decide that the server does not use JNDI for internal operation, 
injecting a LDIF file will be a totally different operation.

I would keep Studio and Server separated here.
> I guess my idea is that this service could be something like a 
> micro-automated-on-startup studio that runs stuff against the engine 
> but is not really built into the core.
More or less the idea, yes.

Alex, can you confirm we are not totally off rails ?

Thanks !

cordialement, regards,
Emmanuel L├ęcharny

View raw message