Hi,
The situation is that we have some nodes in the results list
where not all of the node's ancestors are accessible for the
Session (blocked by our AccessManager). We receive a
DocOrderNodeIteratorImpl from the query that contains these
nodes, and this iterator tries to sort the nodes before the
first method call that accesses them. The comparator then
gets an AccessDeniedException from the getAncestor() of one
of the nodes, and removes these nodes with unaccessable
This seems correct to me, isn't?
Is it? I really don't know, but it is a least a behaviour that I was
not aware of.
To clarify the situation: I have a node with the path a/b/c in the
XPath query result, node c can be accessed, but a and b cannot. But
the node c will then also be removed from the result list, because
the document order cannot be created because of its unauthorized
ancestors. So I have the situation that node c will be removed from
the result although is is an authorized and accessible node, only its
ancestors are not.
If I think it through, It is somehow logical in itself: default for
missing "order by" specification is to create document order ->
document order cannot be created if ancestors are not accessible ->
node is not in the result. But it is a kind of pitfall when you're
not aware of it.
ancestors from the node list. It also looks like the
Comparator directly removes both compared nodes from the
result list if one of them throws an Exception when being compared.
And this is the actual error/problem, isn't? If correct, only the node
that cannot be accessed should be removed, right?
Yes, I would also consider that to be wrong, it should not behave
like that.
Which version of Jackrabbit are you using? First of all, for
JackRabbit
1.5 the default setting for respectDocumentOrder will be false. For <
1.5 it is true. You can configure it to false/true by adding
<param name="respectDocumentOrder" value="false"/>
To you <SearchIndex> element in repository.xml
I use Jackrabbit 1.4. I implemented the solution the Sébastien
suggested, adding a "order by @jcr:score" to the query. Works very
well for me.
Regards and Thanks,
Jan
