However, after trying this and reading the docs more closely, this is only going to tell me if a child node is added to a my:type node, or deleted from a my:type node. I did not realize that the node type restriction applied to the associated parent node.
Yes, this is unfortunately correct and is outlined in section 126.96.36.199.3 of the JSR-283 specification.
Given this, it seems that in general, all I can really observe are changes to my:type nodes, not the creation or removal of the my:type nodes themself. It seems like I need to register an event listener without any node type restrictions, and thus receive events for all nodes, and put the my:type specific code in the EventHandler. This seems like it is going to be inefficient since I'll be getting events for all nodes - not just the few that I'm interested in.
Any thoughts/suggestions how to observe the creation/deletion of nodes of a specific type, or am I missing something obvious.....
I don't know of another way of doing this. I would say that ModeShape has to do a lot more work internally when an event listener is registered with a restriction on the node type - we also have to look up the parent node, get the primary type and mixin types, and then determine if any of the types match or are subtypes of any of the node types specified when registering the listener. So with ModeShape 2.x doing the checks you outlined above may not really be that less efficient than if we did it internally.
Now, having said that, I do hope we can make this more efficient in ModeShape 3 (by passing parent node type information into our internal change event, saving the code that calls the listeners the work of having to look up this information). And we may even be able to add support for registring a listener based on the node type of the child, but obviously this would be ModeShape specific. If you'd like this feature, please log a feature request in our JIRA.
Thanks for the response. For now, I will register a single EventHandler that will determine the correct action inside the handler, and not use node type restriction. I'll wait until 3.0 to evaluate whether this approach is acceptable from a performance perspective long term. For my applications, aside from an initial bulk XML import - in which I don't care about observation - the user transaction rate should be fairly low, so this just might be acceptable. I can turn off observation during initial loads, so this could work. If it does not, I will log the JIRA enhancement request.