Thanks Michael, that has indeed fixed the problem, and demonstrated that the error was entirely mine!

On 15/06/2008 23:15, "Michael Kay" <> wrote:

You don't appear to be closing the output stream. The API specification of Serializer.setOutputStream() makes clear that the caller is responsible for closing the stream.

I've no idea if this accounts for the problem. However, the documentation for DeflaterOutputStream suggests that close() is a significant operation, whereas the documentation for ByteArrayOutputStream says that close() has no effect. So you would expect different behaviour in the two cases.

Michael Kay


From:  [] On Behalf Of Jackson,  Bruce
Sent: 15 June 2008 22:52
To: Mailing list for the  SAXON XSLT and XQuery processor
Subject: Re: [saxon] Using Saxon 9B  with DeflaterOutput/InflaterInput Streams

The answer is that (a) the first transformation is  very expensive in time relative to the second (typically a factor of 20), and  (b) I don’t need to perform the first stage transformation very often, but I  do the second (which will vary depending on the operation invoked). What I  don’t want to do is to keep invoking the first transformation, and therefore I  adopted the approach of holding the result of the first stage transformation  in memory (although I could have obviously written this to disk).

This  worked fine with the raw ByteArrayInput/OutputStream classes, but when I  sought to optimize the storage of this data, I’ve run into this rather  unobvious problem.

On 15/06/2008 21:58, "Michael Kay" <> wrote:

I don't know why this is happening, but my first  reaction is, I don't know
why you are taking this approach. The second  transformation is going to
build its input document into a tree in  memory; this tree will occupy about
5 times the size of the byte array,  so compressing the byte array is not
going to help very much. It would be  far better to dispense with the byte
array entirely and have the first  transformation write its output to a tree
which the second transformation  can use directly. This also saves you the
serialization and parsing  costs, which can take as long as the
transformation itself.

The  class XsltTransformer implements the Destination interface, so you  can
simply use the second XsltTransformer as the destination of the  first.

Michael Kay

>  -----Original Message-----
> From:
>  []  On Behalf
> Of Jackson, Bruce
> Sent: 15 June 2008 18:02
>  To:
>  Subject: [saxon] Using Saxon 9B with
> DeflaterOutput/InflaterInput  Streams
> In some code I'm writing, I'm doing a 2-stage  transform using Saxon.
> First, I read an base XML document and  transform it into an
> intermediate XML format. I then wish to hold  this
> intermediate form in memory and perform a second
>  transformation on it into the final form. The nature of this
> second  transformation will depend on which particular method
> is called on  my
> client: for each method, I have a corresponding transformer  object.
> The intermediate in-memory document may well be  large, hence
> I thought it would be a good idea to hold it in a  compressed
> form, which leads me to my problem.
> I  have the following method to compress the base XML document
> into the  intermediate form:
> synchronized void transformLibrary()  {
>     ByteArrayOutputStream buffer = new  ByteArrayOutputStream();
>      DeflaterOutputStream dos = new  DeflaterOutputStream(buffer);
>     Serializer  destination = new Serializer();
>      destination.setOutputStream(dos);
>      transformer.setDestination(destination);
>          try {
>              transformer.setSource(iTunesSource);
>              transformer.transform();
>              data  = buffer.toByteArray();
>          } catch(SaxonApiException  sx) {
>              sx.printStackTrace();
>          }
> }
>  And then fetch it back out again as the source for the second
>  transformation:
> synchronized public StreamSource getSource()  {
>     InflaterInputStream iis = new  InflaterInputStream(
>          new  ByteArrayInputStream(data));
>     return new  StreamSource(iis);
> }
> When I run the code,  the first call (to transformLibrary())
> works without complaint.  However, when I perform the second
> transform by calling getSource(),  I get the following:
> Error on line 1 column 1758323
>    SXXP0003: Error reported by XML parser:
> Premature end of  file.
> net.sf.saxon.s9api.SaxonApiException:
>  org.xml.sax.SAXParseException: Premature end of file.
>      at
>      at
>  net.sf.saxon.s9api.XsltTransformer.setSource(
>  I've scratched my head on this once, because (obviously) I've
> tried  this directly onto a ByteArrayInput/OutputStream
> without the  compression classes, and it works great. Thus, it
> appears that  something in Saxon is causing a problem with the
> compression classes  (or I'm being a complete dullard...).
> Any  thoughts?
>  --------------------------------------------------------------
>  -----------
> Check out the new Marketplace.
>  It's the best place to buy or sell services for just about
> anything  Open Source.
>  _______________________________________________
> saxon-help mailing  list archived at

Check  out the new Marketplace.
It's the best place to buy or  sell services for
just about anything Open Source.
saxon-help  mailing list archived at