RE: Using XSLProcessor.parse(InputStream source) with XT 19991105

[Diarmuid Mac Carthy <Diarmuid@xxxxxxxx>]

I discovered what the problem is with this.  I figure the problem was borne
of ignorance, but I've enclosed the solution in case any other newbies have
similar difficulties.

The byte[] returned from the PipedInputStream XT sends it's output to is
null-terminated.  You need to strip this off before re-submitting the output
to XT.  For example:

   public char[] getStream()
      {
         byte[] XToutput = // get buffer from pipedinputstream
         return (new String(XToutput).trim().toCharArray());
      }

             

Diarmuid Mac Carthy
XIAM Ltd. "The 'Information Router' company
12 Hume Street, Dublin 2, Ireland.
ph: +353 1 638 4858
fx:  +353  1 678 9070
email:  diarmuid@xxxxxxxx
www:  www.xiam.com
 
This document is strictly confidential and is intended for use by the
addressee unless otherwise indicated.
 

-----Original Message-----
From: Diarmuid Mac Carthy 
Sent: Monday, November 15, 1999 7:20 PM
To: 'XSL-List@xxxxxxxxxxxxxxxx'
Subject: Using XSLProcessor.parse(InputStream source) with XT 19991105


Hi,

I'm trying to reparse the result of an XSLT transformation, but with little
success.  This
is a pretty long mail but I hope it has enough information to describe my
problem in 
enough detail that somebody can understand it and hopefully shed some
light...

Briefly, the changes I've made are:

* Registered a PipedOutputStream with XMLOutputHandler and replaced 
     OutputStream out = ...
  with
     PipedOutputStream out = 
        new PipedOutputStream(XSLPipedInputStream.getInstance());

* XSLPipedInputStream is a singleton class I've written that extends
java.io.PipedInputStream and intercepts the output from XMLOutputHandler

* XTDriver is a modification on com.jclark.xsl.sax.Driver which gets a
handle on the 
  output from XMLOutputHandler:

     PipedInputStream m_XMLInputStream = XSLPipedInputStream.getInstance();

The principal is basic and works:

XMLOutputHandler ----> PipedOutputStream ----> XSLPipedInputStream ---> main
driver

*  XMLOutputHandler writes to a PipedOutputStream which is connected to a
singleton
   instance of XSLPipedInputStream which in turn is used by the driver
class.  I've
   included an extra method on this class which returns the internal
PipedInputStream 
   buffer:

      public byte[] getStream() {
           return buffer;
       }

    When I process an XML doc with an XSLT script, I can access the
resulting doc and 
    print it out from the driver class:

         m_xsl.loadStylesheet(fileInputSource(p_inXSLFile));
         m_xsl.parse(fileInputSource(p_inXMLFile));         

         System.out.println("Transformed XML:" + 
              new String(m_XMLInputStream.getStream());

    and the expected transformations have happened.

    I've included the XML and XSLT scripts below to show the simple an
example I'm 
    trying to get working.

    The XML:

    <MESSAGE>
       <DATA>
          <ADDRESS>hello</ADDRESS>
       </DATA>
    </MESSAGE>

    The XSL:

    <?xml version="1.0"?>
    <xsl:stylesheet 
         version="1.0" 
         xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
    <xsl:output method="xml" omit-xml-declaration="no"/>

      <xsl:template match="/">
        <xsl:copy-of select=".">
           <xsl:apply-templates
               select = "*|@*|comment()|processing-instruction()|text()"/>
           </xsl:copy-of>
        </xsl:template>
      </xsl:stylesheet>   


    So the initial transformation works fine, but when I try and redirect
that transformed
    output back into the XSLProcessorImpl it falls down:

       m_xsl.loadStylesheet(fileInputSource(p_inXSLFile));
       m_xsl.parse(fileInputSource(p_inXMLFile));         

       // And instead of printing the transformed output out, rerun the
output against
       // the current sheet, so we'd expect to see exactly the same output a
second
       // time round

       BufferedReader l_br =
              new BufferedReader(new InputStreamReader(m_XMLOutputStream));
       InputSource l_source = new InputSource(l_br);
       l_source.setEncoding("UTF-8");

       // m_xsl is an instance of XSLProcessorImpl.  
       m_xsl.parse(l_source);

   This just hangs.  I've debugged it and traced the problem down to
      package com.jclark.xml.parse.EntityParser.parseDocumentEntity which
seems to
   hang inexplicably on the parseMisc() operation.  I've examined the
variables associated
   with this and confirmed that the encoding class is UTF8Encoding.  It
falls over on
  	switch (tokenizeProlog()) {
   within parseMisc() which can't be evaluated when reparsing the
transformed XML, although
   it works fine on the original first run...

  
I'm completely stumped...I've checked through the XSL-List archives and
tried various
combinations of encoding schemes and systemIds, using BufferedInputStream
and ByteArrayInputStream in place of the Reader idea, but to no avail.

If anybody has come across this or can shed some light on the problem I'd
really appreciate it.

Best regards,
Diarmuid

         

Diarmuid Mac Carthy
XIAM Ltd. "The 'Information Router' company
12 Hume Street, Dublin 2, Ireland.
ph: +353 1 638 4858
fx:  +353  1 678 9070
email:  diarmuid@xxxxxxxx
www:  www.xiam.com
 
This document is strictly confidential and is intended for use by the
addressee unless otherwise indicated.
 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list