Ok the more I think about this structure the more useful I think it is for us in many ways.I'm thinking of making this the main structure to store partitions in the DirectoryServiceclass rather than using a list of partition configurations. It helps with some of the
refactoring that I would like to do with the configuration.

Also Emmanuel I'd like to see if we can break out the search (lookup) functionality
into a visitor for the tree. As an example you can look at the way this is done withthe filter AST in o.a.d.shared.ldap.filter
. Here a visitor can be responsible for addingnew nodes and removing new nodes instead of adding the code to do this into thenode classes themselves.

I just worked the clarity of it a bit. Essentially you're building a tree that is being used as a rapid lookup structure to find partitions corresponding to the
DN of the entries are contained by a partition. I simply renamed a few things in commit 556176 to make it clear as to what you're doing or at least what I think you are doing. Notice how much more clear it is when I just renamed
the following classes and moved them into an inner package called o.a.d.s.c.partition.tree:

I hope this was the correct interpretation of what you meant by these names.Please correct me if I am wrong.

There still are some things that confuse me like how the lookups are done. Could
you add some documentation to describe it? Also it seems you are sometimes usingthe partition suffix to check for matching and sometimes using the rdn. Could youclarify when one is used over the other? Perhaps breaking up complex statements
which you join together like this below will make it easier to understand:

Also btw how the index parameter is being used in this recursion is a bit confusing could you clarify?

I think this data structure might be better integrated directly into the Partition andPartitionNexus interfaces. Right now you use it as an alternative data structure in the
nexus. Perhaps we could make nexus into a branch node and have it contain othernexus objects? Meaning a nexus should be what here is modeled as a BranchNode. A non-nexus Partition can be the equivalent of a LeafNode. This way the data structure
is directly integrated into the architecture rather than having it used in as an alternativedata structure just in the nexus. This way we can gain nested nexus' and use the structurein an integrated fashion.

Furthermore I know you dislike "patterns" but please try to use the correct terminology when you are designing them. I know you old timers just do patterns without getting into the jargon of it all but it helps communicate what you are doing better to us newbies.
People understand tree structures and the language associated with them verses thingslike PartitionContainer and PartitionHandler. If this continues I'm going to be totally lost.

On 7/13/07, Alex Karasulu <akarasulu@apache.org> wrote:> Hi,
>> I'm looking through this code and it's painful especially with the names
> chosen for the interface,> and the implementations. I'm going to start reworking it a bit so it can be> better understood at> first glance.>> Alex>