You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by "Eder, Johann" <jo...@manz.at> on 2010/08/10 08:37:36 UTC

Upgrade to 1.6.2 and Lists are treated differently?

Hi there,

First, I would like to say thank you for a great product. We have been using it since 2007 in a production environment (for cms), and publishing content from the repository to static files for reading.

Mainly because of performance reason (content is growing and growing) we recently tried to upgrade the web-application from 1.4.5 to 1.6.2. 
Two years ago I upgraded from 1.3 to 1.4.5 without any problems. This time it was different.
I change all api and deleted the workspace index. The application started successfully with one warning because of the DOCTYPE..
I changed this in the repository config file. After restarting any xpath query returned an unsorted result. 
So I investigated and found that lucene had to have an new parameter in the config file: <param name="respectDocumentOrder" value="true"/>
Afterwards the expected behaviour was seen: the nodes where ordered as under version 1.4.5 
This is necessary. 

The troubles started when using the application. There was no Exception but the results of the application where wrong. I realized that Lists are treated differently for example:

    public static int getFootnoteNumber( Node fn, Vector<Node> footnotes) throws Exception {
        if (!footnotes.contains(fn)) return 0;
        return (footnotes.indexOf(fn)+1); 
    }

Where fn is a jcr Node (with uuid, etc.) and footnotes is the result of an xpath query (without uuid, etc.) like
/biblio/ns:Norm[14]/ns:Komment/ns:Thought/ns:Text/p/fn
/biblio/ns:Norm[14]/ns:Komment/ns:Thought/ns:Text/p/fn[2]
...

Before version change to 1.6.2 getFootnoteNumber returned the correct footnote number and afterwards always 0. The indexOf method didn't return anything meaningful too.

The question for me is: is this a Jackrabbit thing or not...
and how to solve it performantly...

Thanks.

Johann

 

Re: AW: search for non-breaking spaces

Posted by Alexander Klimetschek <ak...@adobe.com>.
On 29.10.10 15:03, "Eder, Johann" <jo...@manz.at> wrote:

>Hello Fabian,
>
>thanks for the hint.
>
>Unfortunately it doesn't work.
>
>I use Java and UTF-8 Encoding.
>Other text strings like 'house' etc. are found...only Non Breaking Spaces
>are not...
>
>
>Any other hint?

I would guess this char is (correctly) detected as whitespace by the
Lucene full text analyzer and hence you can't search for it.


Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel





AW: search for non-breaking spaces

Posted by "Eder, Johann" <jo...@manz.at>.
Hello Fabian,

thanks for the hint.

Unfortunately it doesn't work.

I use Java and UTF-8 Encoding.
Other text strings like 'house' etc. are found...only Non Breaking Spaces are not...


Any other hint?

Johann



-----Ursprüngliche Nachricht-----
Von: Fabián Mandelbaum [mailto:fmandelbaum@gmail.com] 
Gesendet: Donnerstag, 28. Oktober 2010 16:36
An: users@jackrabbit.apache.org
Betreff: Re: search for non-breaking spaces

Hello Johann,

did you try with _x0020_ ?

On Thu, Oct 28, 2010 at 10:34 AM, Eder, Johann <jo...@manz.at> wrote:
> Hi there,
>
> has anyone an idea how to search for non-breaking spaces ?
>
> I used '\u00A0' or '&#160;' or '&nbsp;' which does not work:
>
> String xPath = "/jcr:root/bibliothek//*[jcr:contains(.,'\u00A0')]";
>
> Result is 0.
> Thanks.
>
> Johann
>
>
>



-- 
Fabián Mandelbaum
IS Engineer

Re: search for non-breaking spaces

Posted by Fabián Mandelbaum <fm...@gmail.com>.
Hello Johann,

did you try with _x0020_ ?

On Thu, Oct 28, 2010 at 10:34 AM, Eder, Johann <jo...@manz.at> wrote:
> Hi there,
>
> has anyone an idea how to search for non-breaking spaces ?
>
> I used '\u00A0' or '&#160;' or '&nbsp;' which does not work:
>
> String xPath = "/jcr:root/bibliothek//*[jcr:contains(.,'\u00A0')]";
>
> Result is 0.
> Thanks.
>
> Johann
>
>
>



-- 
Fabián Mandelbaum
IS Engineer