I am a bit puzzled by the sequence of events that are observed when a set of nodes are added or removed. It appears that if a parent node and a child node are added, they are in inverse sequence (child first, parent second). In my case, I have an event listener registered on a workspace, waiting for nodes to be added or removed. If a node is added, it transforms it and adds it in another workspace. If it is removed, it just removes from the destination workspace.

The problem is that when a set of nodes is added, say for instance a nt:file/nt:resource pair, the nt:resource event come first, and the event listener cannot really add it to the destination workspace yet as the parent doesn't exists ( a PathNotFound exception is thrown). The workaround has been to copy all the add events in a LinkedList (and the remove in another) before starting looping, and to execute the "add" linked list in reverse order.

Of course, using Workspace.clone is not an option because nodes need to be transformed before being added. I did not see anything in the current specs (and I did not have a chance yet to review JSR-283), but is there a reason for this inversion of order?

Thanks.
Alessandro.

Reply via email to