Re: Node added event type filter applies to parent node
Vidar Ramdal wrote I'm adding nodes to a parent node. The parent node has nt:primaryType=sling:OrderedFolder, while the child node I'm adding has nt:primaryType=slingevent:Event. Now, I have an event listener set up to receive NODE_ADDED events with nodetype slingevent:Event. The event listener is never invoked, but I can see that an event is being triggered, by having a breakpoing in o.a.j.c.observation.EventConsumer. Upon investigating, it seems the event is filtered out, because it reports the node type of the parent node (sling:OrderedFolder) instead of the node type of the child node being added (slingevent:Event). Is this the expected behaviour? On Mon, Sep 27, 2010 at 6:34 PM, Carsten Ziegeler cziege...@apache.org wrote: Funnily I stumbled across the same problem last week - actually the behaviour is correct. The spec states that the node type of the parent item is checked - in case of node added/removed events, this is the parent node. I think this limits its usage but its the spec... Thanks for the clarification! Looks like we have a bug in Sling, then. I'll investigate some more and post a bug there. (Cross-posting to d...@sling) -- Vidar S. Ramdal vi...@idium.no - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 22 00 84 76 Quando omni flunkus moritatus!
Re: Node added event type filter applies to parent node
Vidar Ramdal wrote I'm adding nodes to a parent node. The parent node has nt:primaryType=sling:OrderedFolder, while the child node I'm adding has nt:primaryType=slingevent:Event. Now, I have an event listener set up to receive NODE_ADDED events with nodetype slingevent:Event. The event listener is never invoked, but I can see that an event is being triggered, by having a breakpoing in o.a.j.c.observation.EventConsumer. Upon investigating, it seems the event is filtered out, because it reports the node type of the parent node (sling:OrderedFolder) instead of the node type of the child node being added (slingevent:Event). Is this the expected behaviour? On Mon, Sep 27, 2010 at 6:34 PM, Carsten Ziegeler cziege...@apache.org wrote: Funnily I stumbled across the same problem last week - actually the behaviour is correct. The spec states that the node type of the parent item is checked - in case of node added/removed events, this is the parent node. I think this limits its usage but its the spec... On Mon, Sep 27, 2010 at 6:54 PM, Vidar Ramdal vi...@idium.no wrote: Thanks for the clarification! Looks like we have a bug in Sling, then. I'll investigate some more and post a bug there. Never mind this - it seems it was fixed with SLING-1494. -- Vidar S. Ramdal vi...@idium.no - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 22 00 84 76 Quando omni flunkus moritatus!
Re: Node added event type filter applies to parent node
Vidar Ramdal wrote Vidar Ramdal wrote I'm adding nodes to a parent node. The parent node has nt:primaryType=sling:OrderedFolder, while the child node I'm adding has nt:primaryType=slingevent:Event. Now, I have an event listener set up to receive NODE_ADDED events with nodetype slingevent:Event. The event listener is never invoked, but I can see that an event is being triggered, by having a breakpoing in o.a.j.c.observation.EventConsumer. Upon investigating, it seems the event is filtered out, because it reports the node type of the parent node (sling:OrderedFolder) instead of the node type of the child node being added (slingevent:Event). Is this the expected behaviour? On Mon, Sep 27, 2010 at 6:34 PM, Carsten Ziegeler cziege...@apache.org wrote: Funnily I stumbled across the same problem last week - actually the behaviour is correct. The spec states that the node type of the parent item is checked - in case of node added/removed events, this is the parent node. I think this limits its usage but its the spec... On Mon, Sep 27, 2010 at 6:54 PM, Vidar Ramdal vi...@idium.no wrote: Thanks for the clarification! Looks like we have a bug in Sling, then. I'll investigate some more and post a bug there. Never mind this - it seems it was fixed with SLING-1494. I think I finally fixed this in the Sling eventing last week, so current trunk should be fine now. Carsten -- Carsten Ziegeler cziege...@apache.org
