directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: Ldif loader move ?
Date Mon, 17 Mar 2008 18:50:11 GMT
On Mon, Mar 17, 2008 at 12:21 PM, Emmanuel Lecharny <>

> 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

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.


View raw message