directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Moving the configuration beans to core-api
Date Sun, 31 Oct 2010 18:05:37 GMT
On 10/31/10 6:51 PM, Kiran Ayyagari wrote:
>   hi Emmanuel,
> On 10/31/10, Emmanuel Lecharny<>  wrote:
>> Hi guys,
>> now that the configuration branch has been merged back to trunk (with
>> some bump in the road, I must admit : I just fixed some badly merged
> IMO np, what you have done was huge in the branch
>> file, which caused some errors), I'm now checking some classes that may
>> need a bit of refactoring : the Index hierarchy.
>> There is a base Index class, with two main children : AvlIndex and
>> JdbmIndex. There is a third child, named genericIndex, which is only
>> used to deal with junit annotations used to create a new server instance
>> (it's a holder class). I was wondering if it would not be better to use
>> the created IndexBean we have in server-config, but obviously, we can't
>> if the beans are in server-config.
>> I suggest that all those beans are moved to core-api, then used by the
>> core/server-annotations projects to store the server configuration.
>> That would help simplifying the Index hierarchy.
> I initially agreed for move on IRC but on a second though after
> reading this mail I think we
> shouldn't do this:
>   1. Moving all the beans to core-api *might* make other developers to use them
>      everywhere in the code (be it in our server or in their apps) which IMHO not
>      desirable for us.
Hmmm, that's right.
>    2. Having GenericIndex makes creating a index implementation easier and we can
>        introduce a type parameter in the @CreateIndex annotation to
> support various
>        index implementations. e.x @CreateIndex( type=AvlIndex.class, ..)
Well, I still think we should get rid of the GenericIndex, bt if we can 
default to using JdbmIndex if we don't have any type parameter, then we 
can remove the GenericIndex and not use the IndexBean either.

Seems fine. Will try to do that this way.

Emmanuel L├ęcharny

View raw message