You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Martijn Hendriks <ma...@gx.nl> on 2007/03/08 09:08:02 UTC
Observation mechanism bug?
Hi,
We want to use the observation mechanism of Jackrabbit to keep track of
additions of nodes of a certain type. We've created an observation
manager and added a listener like this:
observationManager.addEventListener(myListener,
Event.NODE_ADDED, prefix, true, null, new String[] {"my:type"},
true);
On addition of a node of type my:type, however (from another session
than the observation manager session), the onEvent method of the
listener is not called. It seems that the following code from
EventStateCollection.createEventStates is responsible for this:
// 3. added items
for (Iterator it = changes.addedStates(); it.hasNext();) {
ItemState state = (ItemState) it.next();
if (state.isNode()) {
// node created
NodeState n = (NodeState) state;
NodeId parentId = n.getParentId();
// the parent of an added item is always modified or new
NodeState parent = (NodeState) changes.get(parentId);
NodeTypeImpl nodeType = getNodeType(parent, session);
Set mixins = parent.getMixinTypeNames();
Path path = getPath(n.getNodeId(), hmgr);
events.add(EventState.childNodeAdded(parentId,
getParent(path),
n.getNodeId(),
path.getNameElement(),
nodeType.getQName(),
mixins,
session));
I.e., not the node type of the added node is added to the EventState,
but the node type of the parent node. This seems to conflict with the
spec (copied from the addEventListener JavaDoc):
The set of events can be filtered by specifying restrictions based on
characteristics of the node associated with the event. In the case of
event types NODE_ADDED and NODE_REMOVED, the node associated with an
event is the node at (or formerly at) the path returned by
Event.getPath. In the case of event types PROPERTY_ADDED,
PROPERTY_REMOVED and PROPERTY_CHANGED, the node associated with an event
is the parent node of the property at (or formerly at) the path returned
by Event.getPath:
So is this really a bug, or am I missing something?
Regards,
Martijn Hendriks
<GX> creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: martijnh@gx.nl
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
Re: Observation mechanism bug?
Posted by Tobias Bocanegra <to...@day.com>.
hi,
NODE_ADDED and NODE_REMOVED events are filtered on the parent node
from which a node was added or removed (thats how it's defined in the
spec).
imo, this is not very helpful for applications, especially with the
NODE_REMOVED event where you can't figure out what nodetype the
removed node had.
regards, toby
On 3/8/07, Martijn Hendriks <ma...@gx.nl> wrote:
> Hi,
>
> We want to use the observation mechanism of Jackrabbit to keep track of
> additions of nodes of a certain type. We've created an observation
> manager and added a listener like this:
>
> observationManager.addEventListener(myListener,
> Event.NODE_ADDED, prefix, true, null, new String[] {"my:type"},
> true);
>
> On addition of a node of type my:type, however (from another session
> than the observation manager session), the onEvent method of the
> listener is not called. It seems that the following code from
> EventStateCollection.createEventStates is responsible for this:
>
> // 3. added items
>
> for (Iterator it = changes.addedStates(); it.hasNext();) {
> ItemState state = (ItemState) it.next();
> if (state.isNode()) {
> // node created
> NodeState n = (NodeState) state;
> NodeId parentId = n.getParentId();
> // the parent of an added item is always modified or new
> NodeState parent = (NodeState) changes.get(parentId);
> NodeTypeImpl nodeType = getNodeType(parent, session);
> Set mixins = parent.getMixinTypeNames();
> Path path = getPath(n.getNodeId(), hmgr);
> events.add(EventState.childNodeAdded(parentId,
> getParent(path),
> n.getNodeId(),
> path.getNameElement(),
> nodeType.getQName(),
> mixins,
> session));
>
> I.e., not the node type of the added node is added to the EventState,
> but the node type of the parent node. This seems to conflict with the
> spec (copied from the addEventListener JavaDoc):
>
> The set of events can be filtered by specifying restrictions based on
> characteristics of the node associated with the event. In the case of
> event types NODE_ADDED and NODE_REMOVED, the node associated with an
> event is the node at (or formerly at) the path returned by
> Event.getPath. In the case of event types PROPERTY_ADDED,
> PROPERTY_REMOVED and PROPERTY_CHANGED, the node associated with an event
> is the parent node of the property at (or formerly at) the path returned
> by Event.getPath:
>
> So is this really a bug, or am I missing something?
>
> Regards,
>
> Martijn Hendriks
> <GX> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: martijnh@gx.nl
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Observation mechanism bug?
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Martijn,
the javadoc is indeed not in sync with the spec. I've forwarded this issue to
the jsr 283 expert group to fix the javadoc in the next release.
thank you for reporting this issue.
regards
marcel
Martijn Hendriks wrote:
> It seems that the Javadoc and the PDF spec differ slightly wrt the
> ObservationManager.addEventListener. The pdf spec says:
>
> The set of events can be filtered by specifying
> restrictions based on characteristics of the
> associated parent node of the event. The
> associated parent node of an event is the parent
> node of the item at (or formerly at) the path
> returned by Event.getPath.
>
> Thus, the Jackrabbit implementation complies to the PDF spec, which is
> also to be considered normative.
RE: Observation mechanism bug?
Posted by Martijn Hendriks <ma...@gx.nl>.
Hi,
It seems that the Javadoc and the PDF spec differ slightly wrt the
ObservationManager.addEventListener. The pdf spec says:
The set of events can be filtered by specifying
restrictions based on characteristics of the
associated parent node of the event. The
associated parent node of an event is the parent
node of the item at (or formerly at) the path
returned by Event.getPath.
Thus, the Jackrabbit implementation complies to the PDF spec, which is
also to be considered normative.
Regards,
Martijn Hendriks
<GX> creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: martijnh@gx.nl
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
> -----Original Message-----
> From: Martijn Hendriks [mailto:martijnh@gx.nl]
> Sent: Thursday, March 08, 2007 9:08 AM
> To: dev@jackrabbit.apache.org
> Subject: Observation mechanism bug?
>
> Hi,
>
> We want to use the observation mechanism of Jackrabbit to
> keep track of additions of nodes of a certain type. We've
> created an observation manager and added a listener like this:
>
> observationManager.addEventListener(myListener,
> Event.NODE_ADDED, prefix, true, null, new String[]
> {"my:type"}, true);
>
> On addition of a node of type my:type, however (from another
> session than the observation manager session), the onEvent
> method of the listener is not called. It seems that the
> following code from EventStateCollection.createEventStates is
> responsible for this:
>
> // 3. added items
>
> for (Iterator it = changes.addedStates(); it.hasNext();) {
> ItemState state = (ItemState) it.next();
> if (state.isNode()) {
> // node created
> NodeState n = (NodeState) state;
> NodeId parentId = n.getParentId();
> // the parent of an added item is always
> modified or new
> NodeState parent = (NodeState) changes.get(parentId);
> NodeTypeImpl nodeType = getNodeType(parent, session);
> Set mixins = parent.getMixinTypeNames();
> Path path = getPath(n.getNodeId(), hmgr);
> events.add(EventState.childNodeAdded(parentId,
> getParent(path),
> n.getNodeId(),
> path.getNameElement(),
> nodeType.getQName(),
> mixins,
> session));
>
> I.e., not the node type of the added node is added to the
> EventState, but the node type of the parent node. This seems
> to conflict with the spec (copied from the addEventListener JavaDoc):
>
> The set of events can be filtered by specifying restrictions
> based on characteristics of the node associated with the
> event. In the case of event types NODE_ADDED and
> NODE_REMOVED, the node associated with an event is the node
> at (or formerly at) the path returned by Event.getPath. In
> the case of event types PROPERTY_ADDED, PROPERTY_REMOVED and
> PROPERTY_CHANGED, the node associated with an event is the
> parent node of the property at (or formerly at) the path
> returned by Event.getPath:
>
> So is this really a bug, or am I missing something?
>
> Regards,
>
> Martijn Hendriks
> <GX> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: martijnh@gx.nl
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
>