Hi Mark, You're right about that. As you point out it is essentially optional for a repository to report the removal of all subnodes in a removed tree. Obviously this was done because the potential performance hit.
In JSR 283 we are re-writing the observation section and considering expanding the vocabulary of event types to be more semantically meaningful (e.g., a "move" instead of the disconnected "remove" plus "add") Maybe there is room to address this issue as well. You can get the current draft here: http://jcp.org/aboutJava/communityprocess/pr/jsr283/ And send comments here: [EMAIL PROTECTED] Best, Peeter On 8/22/07, Mark Waschkowski <[EMAIL PROTECTED]> wrote: > Hi, > > I am trying out the listener capabilities of Jackrabbit, and it appears to > me that Jackrabbit does what it must but not what it should, according to > spec. > > As per JCR spec: > "8.3.7.4 Removing a Child Node > When a node is removed, a NODE_REMOVED event must be generated > for the node on which the remove was called. Additionally, an > implementation should also generate a NODE_REMOVE or > PROPERTY_REMOVE (as appropriate) for each item in the removed > subtree. " > > If I register a listener like so: > observationManager.addEventListener(listener, Event.PROPERTY_REMOVED | > Event.NODE_REMOVED, "/", true, null, null, false); > > (note the Event.PROPERTY_REMOVED | Event.NODE_REMOVED parameter) > > and then I remove a node that contains a property, only the NODE_REMOVED > event is generated (what MUST be done by the spec) but a PROPERTY_REMOVE > event is not generated (which I was also expecting to be part of the > EventIterator in the onEvent method of my listener). Can someone clarify > whether or not this is expected behavior, or if I am off base about how it > should be behaving? > > Thank you, > > Mark > -- Peeter Piegaze Day Software Suite 331 67 Mowat Avenue Toronto Ontario M6K 3E3 Canada office +1 416 987 5720 mobile +1 647 205 2403 fax +1 866 719 3988
