David Jencks wrote:No, from the top of my head, I would say you are right.
> On Mar 17, 2008, at 2:09 AM, Emmanuel Lecharny wrote:
>> 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.
>Well, thinking twice about it, you may be right about the fact that
> 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.
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.
>Yes and no. There are two things in this functionality :
> 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?
- 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 aMore or less the idea, yes.
> micro-automated-on-startup studio that runs stuff against the engine
> but is not really built into the core.
Alex, can you confirm we are not totally off rails ?