You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2008/03/17 10:09:55 UTC
Ldif loader move ?
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.
It will have other impact on the code, like the LdifLoadFilter and
LdifLoadFile will have to migrate to core.jndi.
Otherwise, the LdifFilters configuration parameter is never used, and
the LoadLidfFilter interface is never implemented. Should we keep it ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Ldif loader move ?
Posted by Alex Karasulu <ak...@apache.org>.
On Mon, Mar 17, 2008 at 6:24 PM, Emmanuel Lecharny <el...@gmail.com>
wrote:
> Alex Karasulu wrote:
> >
> > <snip/>
> >
> > 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.
> True. Even JNDI is not the major key point here, as soon as JNDI won't
> be present anymore, we will have a better vision.
> >
> > Might not be worth messing with it until the dust settles unless there
> > is something that the present configuration prevents us from doing.
> Right now, I just asked because there is a comment in the code I found
> interesting :
> //
> ----------------------------------------------------------------------
> // From CoreContextFactory: presently in intermediate step but these
> // methods will be moved to the appropriate protocol service
> eventually.
> // This is here simply to start to remove the JNDI dependency then
> further
> // refactoring will be needed to place these where they belong.
> //
> ----------------------------------------------------------------------
>
Hmmm interesting ... I wonder if this is even still relevant. Thing is
eventually the protocol services will stop using JNDI all together and start
using the Entry API instead. This way they'll be even faster without all
the JNDI overhead as well as the bugs it brings.
>
> > All these big bang refactorings are going to shift many things
> > especially at the end when all the aspects are snapped in place.
> Sadly, I don't expect things to magically snap in place !
Yep. I don't think it's going to be hard: just a lot of rote work. I can
see it all coming together nicely even though this is a drawn out process.
All these refactorings will leave some residue too: there are going to be
lots of places where vestigial code may be left behind. Test cases and
coverage tools can help us find an plug these. Also it will be a good time
after this big bang to do some general cleanup.
> So it's not urgent, as far as we know something should be done... It has
> just to be agreed on and put somewhere in the roadmap :)
>
The relocation of the LDIF loader was so minor to me that I never consider
it to be a roadmap worthy item. Rather why not just add a JIRA and we'll
get to it at some point?
Alex
Re: Ldif loader move ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Alex Karasulu wrote:
>
> <snip/>
>
> 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.
True. Even JNDI is not the major key point here, as soon as JNDI won't
be present anymore, we will have a better vision.
>
> Might not be worth messing with it until the dust settles unless there
> is something that the present configuration prevents us from doing.
Right now, I just asked because there is a comment in the code I found
interesting :
//
----------------------------------------------------------------------
// From CoreContextFactory: presently in intermediate step but these
// methods will be moved to the appropriate protocol service eventually.
// This is here simply to start to remove the JNDI dependency then
further
// refactoring will be needed to place these where they belong.
//
----------------------------------------------------------------------
>
> All these big bang refactorings are going to shift many things
> especially at the end when all the aspects are snapped in place.
Sadly, I don't expect things to magically snap in place ! But there is a
timing to complete a puzzle : first find the corners and the sides,
complete the sides, etc...
So it's not urgent, as far as we know something should be done... It has
just to be agreed on and put somewhere in the roadmap :)
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Ldif loader move ?
Posted by Alex Karasulu <ak...@apache.org>.
On Mon, Mar 17, 2008 at 12:21 PM, Emmanuel Lecharny <el...@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.
Alex
Re: Ldif loader move ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
www.iktek.com
directory.apache.org
Re: Ldif loader move ?
Posted by Stefan Seelmann <se...@apache.org>.
Hi David,
David Jencks schrieb:
>
> an even better solution? Also isn't there some code duplication on this
> functionality between the server and studio?
Yes, that is right. There are different LDIF parsers in studio and the
server. The reason is that they must work differently: The studio LDIF
parser is not just a LDIF-to-JNDI-translator but it is used for the LDIF
editor feature. So it must be error tolerant to allow features like
content assist and syntax highlighting.
Kind Regards,
Stefan Seelmann
Re: Ldif loader move ?
Posted by David Jencks <da...@yahoo.com>.
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.
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.
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? 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.
thanks
david jencks
>
> It will have other impact on the code, like the LdifLoadFilter and
> LdifLoadFile will have to migrate to core.jndi.
>
> Otherwise, the LdifFilters configuration parameter is never used,
> and the LoadLidfFilter interface is never implemented. Should we
> keep it ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>