Attached test case and source code.

To reproduce the exception:

• Load welcomeICEfaces.jsf
• Expand the nodes until the exception is thrown.

I made a custom test, based on the showcase. As seen in the screenshot, the nodes of the tree can be expanded to a very deep level with no issues. The markup in my test page is very similar to the one in the attached test case; the only difference is that my test tree doesn't use different different node types. I'll keep investigating to see if the type attribute has anything to do with the issue or if the problem is in the app code.

I tested using different node types, and there are no issues, as seen in the second screenshot. I'll examine the implementation of the MutableTreeNode and the data factory of the test case to see if there is an issue there.

I tried many different things including the following:

• Integrating the attached test case code as is into the showcase app. The Exception didn't occur, and it was possible to expand the nodes to the deepest level. However, there was a slightly odd behaviour: the root nodes were duplicated, but only one of each pair could be expanded, and when expanding the deepest node; it only works for the second subtree, and both subtrees are expanded at the same time when this is done.
• Integrating my own test tree into the attached test case and building from scratch. In this case, my test tree didn't show any issues and worked normally.
• Copying all the context parameters from the web.xml in the showcase to the attached test case. This didn't make a difference.
• Changing the use of CopyOnWriteArrayList in the factory class to regular ArrayList's. This didn't make a difference either.
• Changing the use of arrays to ArrayLists in my own test tree (to see if the issue could be related to lists), but this didn't change anything; everything kept working normally.

There doesn't seem to be an issue with the component code itself.

In the end what made things work normally in the attached test case was to simply comment out the second add() call on the planList list, in the getSingleRoot() method of the PlanTreeDataFactory class. In this case, all the nodes could be expanded to the deepest level and there were no odd behaviours or exceptions.

Most likely, the issue is in the PlanTreeDataFactory class itself, which uses a very convoluted approach to building the tree model. First of all, it uses iterators on various lists but also adds new elements to those very lists while iterating them, which is just not a good practice, even if taking thread-safe measures to avoid ConcurrentModificatonException's by using the CopyOnWriteArrayList class. The algorithm also seems to use separate lists for each node level/type and only allows one instance of each node with the same name/label. So, it seems like certain nodes can be shared between different roots. This is what caused the odd behaviour I was seeing that I describe in the first point above. I don't see the point in doing this. The node objects should be unique and only belong to one root. Multiple node objects could have a reference to the same data object, but the node objects should not be shared.

I'm not familiar with the purpose of this application, but it certainly can be improved by using more standard patterns and best practices.

I'm closing this issue as invalid for now.