Marcel Reutegger schrieb:
...
hmm, the more I think about it, we might have to deal with this issue at
other occasions. It may happen that a node is returned by a query that
has never been requested, but its parent node has. assuming that the
jcr2spi layer still has the old version of the parent node it will not
see the new child node entry in there for the node returned in the query.
...
I can resolve my original problem with the change below...:
---
src/main/java/org/apache/jackrabbit/jcr2spi/state/WorkspaceItemStateFactory.java
26 Oct 2006 12:20:08 -0000 1.2
+++
src/main/java/org/apache/jackrabbit/jcr2spi/state/WorkspaceItemStateFactory.java
3 Nov 2006 14:18:50 -0000
@@ -96,7 +96,8 @@
NodeState parent = (parentId != null) ? (NodeState)
ism.getItemState(parentId) : null;
if (parent != null) {
- return parent.getChildNodeEntry(info.getQName(),
info.getIndex()).getNodeState();
+ ChildNodeEntry child =
parent.getChildNodeEntry(info.getQName(), info.getIndex());
+ return child != null ? child.getNodeState() :
createNodeState(info, parent);
} else {
return createNodeState(info, parent);
}
...however once I do that - as expected - other problems surface.
Looking at JCR2SPIs NodeImpl and HierarchyManagerImpl it seems that the
only way to access a Node by absolute path is to recursively access all
parent nodes, visiting their children.
This seems to be not only inefficient, but may also cause a problem when
the given user doesn't have read access to all parent nodes...
Shouldn't we have something like:
NodeId RepositoryService.getNodeId(QPath path);
Best regards, Julian
