On Mon, Mar 17, 2008 at 12:21 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
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 ?

No these are some good ideas.  I like David's idea of making it a separate configurable component.  However I also think it's going to change a lot as we remove JNDI from the picture with the final steps in the big bang refactoring.

Might not be worth messing with it until the dust settles unless there is something that the present configuration prevents us from doing.

All these big bang refactorings are going to shift many things especially at the end when all the aspects are snapped in place.  My general rule of thumb is not to mix concerns and changes unless they inhibit something along the path of the current objective.