directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] [BigBang] Status Report
Date Mon, 08 Oct 2007 15:19:04 GMT
Hi Emmanuel,

On 10/8/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> Thanks a lot Alex for this repport ! It gives us a lot of visibility,
> and will help to get in synch when you will be done with all those
> configuration cleanup.


NP this is a must as the team grows.  We're not in Kansas anymore toto!

In the same time, - beside breaking the trunk with stupid commits ;)
> -, I'm finishing to define a new version of JNDI classes used
> internally to the server, like :
> - ServerEntry, a replacement for Attributes
> - ServerAttribute, a replacement for Attribute
> - Value, a handler for attributes' values (JNDI uses Object)
> - ServerModification, a replacement for ModificationItem
>
> This is also done, tests included. Some more classes and interfaces
> have to be replaced, and I have listed all those classes and
> interfaces here :
> http://cwiki.apache.org/confluence/display/DIRxPMGT/JNDI+removing
>
> The biggest part will be to replace the NamingEnumeration which is
> used everywhere, and the SearchResult. The other classes are used from
> place to place, and can be removed quite easily.


Yes we need a ServerResult object as well as a Cursor interface which should
be more like a jdbc ResultSet.  I have some ideas on this from past
experiences.
Just quickly the Cursor should not be pre-fetching in the constructor as we
do
now with NamingEnumerations.  This is why JDBC has getObject() and next()
but next returns a boolean.  It does not prefetch but drives the initial
fetch in the
loop.  Anyways we can discuss this in more detail.  However this work can
start
happening soon in the JDBM implementation as long as we have tools to
butress
the changes by converting back to what higher levels of the server expect in
terms
of JNDI objects like NamingEnumeration and SearchResult.

Another task I'm working on, and I saw that Stefan Szörner has also
> working on it,  is to speed up integration tests. It some point, tests
> are getting soooo long that we are reluctant to launch them before
> committing (I did it a couple of time, and it was a disaster, but
> having to wait 20 minutes each time is just overkilling). I really
> think we can have tests running in less than 5 minutes, and I will
> work on that this week, waiting for Alex to finish his cleanup.


Actually this can start happening now.  You have most of what you need to do
this.  We might
step on each others toes on occasion but these tests are killing us.  Having
them out of the
way ASAP before Phase II might help accelerate our big bang effort.

Thanks,
Alex

Mime
View raw message