You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Frédéric Glorieux <fr...@ajlsm.com> on 2002/08/23 11:32:29 UTC
Xalan, xsl fucnction document(), caching ?
We are developping with cocoon (1 and now 2), and in our project an
operation could be :
transform 100 000 documents with the same xsl.
Under cocoon1 we worked with Saxon, for the moment with cocoon2 it's xalan.
We saw a big fall in performances in this new configuration, especially when
the xsl uses
the function document().
In the core.log we tried to guess the meaning of the calls, see the example
below,
It's a simple localized xsl, wich is searching in itself for each messages
(like some Michael Kay samples).
DEBUG (2002-08-23) 10:54.54:135
[core.xslt-processor](/sdx/sdx/admin/identities.xsp)
Thread-13/XSLTProcessorImpl: xslSource =
org.apache.cocoon.components.source.FileSource@739aa3, system id =
file:/D:/server/webapps/sdx/sdx/admin/xsl/identities.xsl
DEBUG (2002-08-23) 10:54.54:166
[core.xslt-processor](/sdx/sdx/admin/identities.xsp)
Thread-13/XSLTProcessorImpl: resolve(href = , base =
file:/D:/server/webapps/sdx/sdx/admin/xsl/identities.xsl); resolver =
org.apache.cocoon.environment.http.HttpEnvironment@318293
DEBUG (2002-08-23) 10:54.54:166
[core.xslt-processor](/sdx/sdx/admin/identities.xsp)
Thread-13/XSLTProcessorImpl: resolve(href = , base =
file:/D:/server/webapps/sdx/sdx/admin/xsl/identities.xsl); resolver =
org.apache.cocoon.environment.http.HttpEnvironment@318293
DEBUG (2002-08-23) 10:54.54:166
[core.xslt-processor](/sdx/sdx/admin/identities.xsp)
Thread-13/XSLTProcessorImpl: resolve(href = , base =
file:/D:/server/webapps/sdx/sdx/admin/xsl/identities.xsl); resolver =
org.apache.cocoon.environment.http.HttpEnvironment@318293
DEBUG (2002-08-23) 10:54.54:166
[core.xslt-processor](/sdx/sdx/admin/identities.xsp)
Thread-13/XSLTProcessorImpl: resolve(href = , base =
file:/D:/server/webapps/sdx/sdx/admin/xsl/identities.xsl); resolver =
org.apache.cocoon.environment.http.HttpEnvironment@318293
...
Does it means that identities.xsl is throwing a request to cocoon at each
<xsl:value-of
select="document('')/xsl:stylesheet/messages[@xml:lang=$lang]/message[@id=$i
d]"/> ? It could explains our big problem of performances.
Does someone meet the problem ?
Is it a configuration of xalan by cocoon ?
(sorry if it's a xalan problem, I tryed to find an answer in xalan lists
also).
Workaround to avoid the document() function (xinclude ...) is not a solution
for us (messages in our case is presentation, not generation).
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Xalan, xsl fucnction document(), caching ?
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
Thank you all,
Some replies on different points
> I have improved performance by using an <xsl:variable> at the top of my
xslt
> and give it the value of document(...). Later on you just refer to the
> variable.
> It's a Xalan problem, it got a bugzilla id, but it's scheduled to be fixed
at dooms day ...
> In fact the result of document() are correct !!
I'm working with a top variable in xsl. I thought that it was in XSL spec
that an XSLT processor have to cache the content.
> Why don't you use saxon then?
We need to migrate on cocoon2.03 to use Saxon, now everything seems to be
correct in core.log.
But Saxon is more on matching, careful with your priorities in templates.
> Have you read this FAQ?
http://xml.apache.org/cocoon/faq/faq-xslt.html#faq-6
>Hmm. I can't understand why you can't include the content of the messages
file using map:aggregate. So you would replace document() with
> '/content_of_messages_file' and live happily ever after ...
We understand the good practice with xsp but look at this example:
I've got a complex xsp (logicsheet generated) wich agregate all my datas.
Displaying theese datas could need :
different static set of messages to localize on params
dynamic lists in case of edition
...
On an xsp working correctly and already compiled, it's probably better to
use document() function to get other infos wich are not part of the document
to show, to navigate, or to edit.
More discussions on theese points could begin on another thread.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Xalan, xsl fucnction document(), caching ?
Posted by Vadim Gritsenko <va...@verizon.net>.
J.Pietschmann wrote:
> Vadim Gritsenko wrote:
>
>> Why don't you use saxon then?
>
>
> Because it's somewhat unintuitive to get it working?
Strange... For me it was as simple as rm -f xalan*; cp saxon*... Works
like a charm, and even faster then current xsltc :) :(
Vadim
> Unfortunately I have my stuff at work, but I think I
> finally succedded with dumping Xalan, putting Saxon
> first in the classpath (depends on the Servlet
> Container), and set the (default JAXP) parser's SAX
> factory and DOM factory to Xerces classes.
>
> J.Pietschmann
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Xalan, xsl fucnction document(), caching ?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Vadim Gritsenko wrote:
> Why don't you use saxon then?
Because it's somewhat unintuitive to get it working?
Unfortunately I have my stuff at work, but I think I
finally succedded with dumping Xalan, putting Saxon
first in the classpath (depends on the Servlet
Container), and set the (default JAXP) parser's SAX
factory and DOM factory to Xerces classes.
J.Pietschmann
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Xalan, xsl fucnction document(), caching ?
Posted by Vadim Gritsenko <va...@verizon.net>.
Frédéric Glorieux wrote:
>We are developping with cocoon (1 and now 2), and in our project an
>operation could be :
>transform 100 000 documents with the same xsl.
>Under cocoon1 we worked with Saxon, for the moment with cocoon2 it's xalan.
>We saw a big fall in performances in this new configuration, especially when
>the xsl uses
>the function document().
>
Why don't you use saxon then?
Vadim
>In the core.log we tried to guess the meaning of the calls, see the example
>below,
>It's a simple localized xsl, wich is searching in itself for each messages
>(like some Michael Kay samples).
>
>
>
...
>...
>Does it means that identities.xsl is throwing a request to cocoon at each
><xsl:value-of
>select="document('')/xsl:stylesheet/messages[@xml:lang=$lang]/message[@id=$i
>d]"/> ? It could explains our big problem of performances.
>
>Does someone meet the problem ?
>Is it a configuration of xalan by cocoon ?
>(sorry if it's a xalan problem, I tryed to find an answer in xalan lists
>also).
>
>Workaround to avoid the document() function (xinclude ...) is not a solution
>for us (messages in our case is presentation, not generation).
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Xalan, xsl fucnction document(), caching ?
Posted by Diana Shannon <sh...@apache.org>.
On Friday, August 23, 2002, at 05:32 AM, Frédéric Glorieux wrote:
> Workaround to avoid the document() function (xinclude ...) is not a
> solution
> for us (messages in our case is presentation, not generation).
Have you read this FAQ?
http://xml.apache.org/cocoon/faq/faq-xslt.html#faq-6
Diana
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>