Hello, > 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? > 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? > > Is this wanted behaviour, that nodes won't be returned by a > query when they cannot be sorted? And is it generally > supported in JackRabbit to have nodes whose ancestors are not > accessible? > > We could work around that by turning off the sorting of the > nodes, we don't need sorted query results here. Is there a > way to achieve this trough JCR or Jackrabbit API? We are > currently doing this by accessing the private > org.apache.jackrabbit.core.query.lucene.QueryImpl object from > the query result through Java reflection, and then calling a > setRespectDocumentOrder(false) on it. But maybe there is a > nicer way (as probably almost any way would be nicer) to > achieve the same result? 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 Regards Ard > > I will attach the XPath query and Exception stack trace from > our log file. > > Best regards and Thanks, > > Jan > >
