qexo-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qexo-general] Strange special character problem


From: Markus Skistad
Subject: Re: [Qexo-general] Strange special character problem
Date: Tue, 14 Feb 2006 08:47:26 +0100

Hello,

After dwelling deeper into the strange character problem I found that the reason kawa returned the wrong character was because the server fed it the error, hence my assumption that kawa caused the error was wrong. However, I've allready stumbled upon yet another problem with my xquery program which I'm pretty sure can be traced back to a Kawa/Qexo memory leak. After running a pretty simple xquery around 10-20 times, tomcat throws me a java.lang.outofmemory error. I've tried it on two separate systems, both giving me the same error. Even after upping the memory limit for tomcat. Listed below is the xquery.

{
let $a := doc("content.xml")/library/libitem
for $b in distinct-values($a/libcat)
order by $b
return
    <div id="panel1">
    <div id="panel1header" class="accordionTabTitleBar">{$b}</div>
    <div id="panel1content" class="accordionTabContentBox">
    <div id="main1" class="main">
    <table style="width:453px;padding:0px;">
    {
    for $x in doc("content.xml")/library/libitem
    where contains($x/occurrence,request-parameter("name", "test")) and contains($x/libcat,$b)
    order by $x/linktext
    return
        <tr><td>
        <img src=""
                <a href=""
                </td><td align="right">{$x/copyright}</td></tr>
    }
    </table>
    </div>
    </div>
    </div>
}


Regards
Markus


On 07/02/06, Per Bothner <address@hidden> wrote:
Markus Skistad wrote:
> I'm using kawa-1.8 against a ISO-8859-1 xml document.

Without a testcase I can't tell if the problem is the the XMLPrinter
(as you hypothesize), but I actually suspect the XML parser.

Kawa's builtin XML parser is rather basic.  It doesn't handle
byte->character handling, but uses the standard Java Reader support.
It specifically does not handle encoding declarations.

Of course one could fix the Kawa XML parser to be more conformant.
but I don't think that makes sense.  Better to switch to using a
more conformant XML parser - specifically a parser conformant to
JAXP.  Since JDK 1.4 comes with a standard XML parser, we should
use that, when available.

The existing Kawa parser is useful as an option, when JAXP isn't
available or when one needs a quick and dirty XML parser.  There
should be a way to select a parser, but the default should be
the JAXP parser when it is available.

This would also give us the option of validation.

I'm not very familiar with JAXP and I haven't had time to spend
on this so far.  A volunteer to look into this would be appreciated.
--
        --Per Bothner
address@hidden   http://per.bothner.com/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]