Thank you Marcel,
In fact, I was just testing jcr:like with jcr:primaryType but I don't
need it on NAME properties.
Therefore, I think I found a bug: tell me if I should open it
queryManager.createQuery("//*[jcr:like(@jcr:primaryType, '%')]",
Query.XPATH);
gives me:
Caused by: java.lang.NullPointerException
at
org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl.initOrderedIterator(DocOrderNodeIteratorImpl.java:170)
at
org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl.hasNext(DocOrderNodeIteratorImpl.java:135)
--
regards,
Raphaël
Marcel Reutegger a écrit :
> Hi Raphaël,
>
> the jcr:like function is acutally not meant to be used with NAME
> properties because it is not required by the spec (see section 6.6.3.3).
> your second statement example works because the index structure is able
> to handle this specific jcr:like expression, but it does not support it
> in general as you have noticed with the last two statements.
>
> please post a jira enhancement request if you feel this is a feature
> that should be included in jackrabbit.
>
> regards
> marcel
>
> Raphaël Franchet wrote:
>
>> Hello,
>>
>> I have got a strange behavior with the jcr:like function:
>>
>> createQuery("//*[@jcr:primaryType='myns:contentLanguage']"... OK
>> createQuery("//*[jcr:like(@jcr:primaryType, '%:contentLanguage')]"... OK
>>
>> but as soon as I use namespaces in jcr:like,
>>
>> createQuery("//*[jcr:like(@jcr:primaryType,
>> '%ns:contentLanguage')]"... KO
>> createQuery("//*[jcr:like(@jcr:primaryType,
>> 'myns:contentLanguage')]"... KO
>>
>> is this a known limitation between jcr:like and namespaces ?
>>
>> Thanks
>>
>> ps: I'm using the HEAD version
>
>
|