Understanding IvmContext

The key to understanding the IvmContext is to understand how the NameNode tree works. The NameNode has five NameNode references:
* lessTree
* grtrTree
* subTree
* parentTree
* parent

The nodes "lessTree" and "grtrTree" have the very same semanics and are treated the same way. They act as references for the leaves or subtrees of an ordinary binary tree. The important thing to note here is that every time we create a new NameNode either in less/grtTree or bind sumething in such we preserve the "parent" (i.e we do not change the parent-child relationship between the JNDI contexts). Whether something is bound to "lessTree" or "grtrTree" depends on the hashcode of the current element of the ParsedName and hashcode of the atomic element of the current NameNode. Of the hashcode is less -> we go to lessTree, if its greater -> we go to grtrTree.

The node "subTree" denotes a change in the paren-child relationship between the JNDI contexts. Every time we create a subTree node or bind something in such we change the "parent". We bind soemthing in the subTree if the hashcode of the atomic name of the current NameNode is the same as the hashcode of the current element of the ParsedName.

The node "parentTree" always points to the inverse direction of less/grtr/subTree and points to the parent node in the phisical layout of the tree. For instance if node "b" is bound to either "a.sub/less/grtrTree", then "b.parentTree" will point to "a".

The node "parent" always points to the last "subTree". This node denotes the parent-child relationship betweens the JNDI contexts.

Now lets give some concrete examples - lets build the NameNode tree for the following JNDI adresses:
* java:app
* java:module
* java:global
* java:comp/env/p1
* java:comp/env/p2
* java:comp/env/p3
* java:comp/env/p4
* java:comp/env/p5

1. First lets normalize th enames and strip "java:".

2. Now we'll bind "app". The component "app" from the ParsedName("app") is different than the atomic name of the root node (which i sthe empty string), so depending on the hashcode we'll go either in lessTree ot grtrTree. For the sake of the example let's go to lessTree. As it's null we create a new NameNode with root node's parent (i.e. null. Remember -> we do not change the parent we we bind in less/grtr) and root node as "parentTree".

3. When binding "module" we follow the same steps as with "app". But let's assume it's hashcode is greater than that of the root node's atomic name and hence bind it in "grtrTree"

4. When binding "comp" we follow the same steps again, but this time both lessTree and grtrTree are taken. So instead of creating new NameNode we'll call either lessTree/grtrTree.bind(). By doing this we now chek if module's hashcode of the atomic name is less/grtr/same as that of "comp". Let's assume it's less. We create a new NameNode with parent=module's parent (i.e. null -> we preserve the parent) and parentTree=module.

5. Unlike "app" and "module", "comp" has subcontexts, so when the new NameNode was created in #4 - its constructor bounded env/p1 ... env/p5. How did this happen ? Every time a NameNode is created, its constructor processes the remaining components from the ParsedName, recursively binding each component to the subTree of the previous one. I.e "env" is bound to the subTree of "comp"; "p1","p2" ... "p5" are bound in the subtree of "env". (Remember every time we descend into a subtree we change the parent)

As a result we get what is the image: