jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juerg Meier <juerg.me...@ctp-consulting.com>
Subject RE: XPATH problem
Date Tue, 01 Apr 2008 11:41:31 GMT
Just for completeness...

I had to reload the JCR from ground-up (export - remove repository - import), now it works
again.  And I really hope this won't happen in production...

-- Juerg

From: Juerg Meier [juerg.meier@ctp-consulting.com]
Sent: Monday, March 31, 2008 3:19 PM
To: users@jackrabbit.apache.org
Subject: XPATH problem


I have a problem in category "query should return something, but it doesn't", too.

One subnode of the rep does not seem to be reachable anymore by xpath queries. The problem
exists since I shut down my app, and temporarely startet magnolia. But I frankly cannot imagine
that this can cause a problem of this sort.

The situation is as follows:

  A (nt:unstructured)
     A1 (nt:unstructured)
     A2 (nt:unstructured)
  B (nt:unstructured)
     B1 (nt:unstructured)
     B2 (nt:unstructured)

The problem is that no query in the /A substree works anymore. They all return empty, including
statements that have worked for months. Finally, I tested something like this:

//element(*, nt:unstructed)

This query returns all nt:unstructured nodes of B, but not of A! The behaviour is the same
for both, application and query tools. I already rebuilt the index, but the effect is still
the same.

Question: could there be a Lucene internal lock? I consider that unlikely, the rebuild would
have solved the problem. Or is there an inconcistence in the JCR that makes a correct indexing
impossible? Also unlikely, as the node tree of A can be navigated without a problem through
the JCR API.

Thus, I'm pretty clouless. Anybody with an idea?


View raw message