cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: XML/HTML serializers buffering everything and using threads.
Date Mon, 24 Feb 2003 11:24:51 GMT

> -----Original Message-----
> From: Bruno Dumon []
> Just found out about some suboptimal serializer things in the current
> Cocoon CVS, and since I didn't find anything relevant in the mail
> archives, I thought I'd just come in and complain.
> There are actually 2 things:
> * the current XML/HTML serializers are performing identity XSL
> transforms (with a real stylesheet!), instead of just serializing. This
> means that they require the building of a complete DTM-tree, effectively
> creating a buffer of all SAX-events entering the serializer. From the
> CVS logs, I see this has been introduced to work around a bug occuring
> in (of all things) the SourceWritingTransformer, though I did not find
> what exactly.
> * by default, cocoon is configured with "incremental-processing" for
> XSL's set to true (this only applies when using xalan, not when using
> xsltc). Since Xalan manages this setting in a static variable, this
> property is shared for all XSL transformers in Cocoon. Since the
> serializer is also performing an XSL transform, it also applies to the
> serializer. Incremental processing is achieved by performing the
> transform on a separate thread. This means that a simple pipeline
> containing a (xalan) XSLT transform and a HTML serializer will already
> use 3 threads (the original request-dispatching thread, and an
> additional thread for each transform). (and the threads created by xalan
> are not pooled).
> So what I would propose is:
> * if the xsl-ing serializer workaround is only required by the SWT, lets
> make this behaviour configurable and make the default serializers not
> use it.
> * and possibly, lets set the incremental-processing to false per
> default. It has an advantage if and only if the processed XML is rather
> large, and the stylesheet is written is such a way that it can actually
> be performed incrementally (for most XSL's I've seen in practical use,
> this is not the case).
> * finally (or better first of all), lets look if the serializer problems
> cannot be solved in xalan.
I personally see this as the right solution... :) I tried to fix this
bug in Xalan several month ago but failed :( (Ok, I only had three hours
time to understand whats going on inside Xalan).
So, best thing in my eyes is to build up some pressure on the xalan team,
so that they will fix this annoying bug.


View raw message