Hi Brian,
thanks for the threaddump, it was very helpful.
turned out again to be a bug, argh...
See: http://issues.apache.org/jira/browse/JCR-192
regards
marcel
Brian Moseley wrote:
Marcel Reutegger wrote:
this is clearly a bug. however, your query will never return any results.
If you want to specify an absolute XPath it must always begin with
/jcr:root otherwise you won't get any results. You may also write a
relative XPath, which would be something like:
bcm/cal//element(*, caldav:resource)[EMAIL PROTECTED]:uid =
'59BC120D-E909-4A56-A70D-8E97914E51A3']
and of course using:
//whatever
will also work because it includes /jcr:root
See spec section 6.6.4.3
thanks for the explanation. i read the section last night before writing
my query code, but not being too familiar with xpath, i admit it did not
make a lot of sense to me :)
i added /jcr:root to the beginning of the statement, which results in:
/jcr:root/bcm/cal//element(*, caldav:resource)[EMAIL PROTECTED]:uid =
'FE532DE3-5036-4C55-BA19-93FA06341B76']
1) when i run this query against an empty subtree (/bcm/cal exists but
has no children), the query returns successfully with no results.
2) when i add /bcm/cal/event1.ics with caldav:uid equal to the above
value and then execute the query, i get the indefinite hang. the thread
dump is here:
<http://builds.osafoundation.org/~bcm/threaddump.txt>
that is what happens within my tomcat-based dav server, where queries
are formulated against subtrees like /bcm/cal.
in contrast, my simple junit test makes queries directly against the
root node, like so:
/jcr:root//element(*, caldav:resource)[EMAIL PROTECTED]:uid = '2']
the unit test also performs steps 1 and 2 above and is successful both
times (no results for the first query, one result for the second). maybe
that gives you another clue.
thanks for your help!
