> > > > AFAIK jcr:data is only indexed in the nodeIndex and not as > a separate > > property, hence I think jcr:contains(jcr:content/jcr:data, 'fusce') > > would not work. > > >>> /jcr:root/nen:content//element(*,nen:resource)[EMAIL PROTECTED]:isarticle > >>> and > >>> @dep:state = 'published' and @nen:type = '1' and > >>> jcr:contains(jcr:content/@jcr:data, > >>> 'fusce')] > > > The thing is, the last one did work with a previous version > of jackrabbit. I'm now on jr 1.4. I might try upgrading to > the latest to see if it fixes it..
Well, just because it shouldn't work like you describe, that if it worked before, I doubt whether it worked correctly (or just by coincidence): It might be that < 1.4 a query like jcr:content/@jcr:data would result in the same query as jcr:content/. (so, < 1.4 you might query for jcr:content/@jcr:data and find hits, but probably, also when the hit was just in, say, the title property instead of jcr:data : you cannot specifically query in *only* jcr:data of a node, at least, AFAIU) The point is, and you can simply see this in the NodeIndexer, that jcr:data is not indexed seperately as a Field in lucene, but gathered in the FULL_TEXT lucene field, together with other nodeScopeIndexed properties (by default all, see [1]) -Ard [1] http://wiki.apache.org/jackrabbit/IndexingConfiguration > > -- > Torgeir Veimo > [EMAIL PROTECTED] > > > > >
