[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: <xsl:message terminate="yes"> results in zero byte

Subject: Re: <xsl:message terminate="yes"> results in zero byte file getting written
From: "Senthilkumaravelan K" <skumaravelan@xxxxxxxxxxxxxx>
Date: Thu, 29 Mar 2007 09:37:07 -0700
Re:  <xsl:message terminate="yes"> results in zero byte
Hi Grant ,
I am also facing similar kind of issue ,during transfor if I have
xsl:message with terminate=yes and it is redirected to System.err and
It does not fall as Exception,
Could you please tell me ,How did you manage to get the text value of
xsl:message in Java context.
It would of real help ,if you share your approach on the same.

Thank,
Senthil

On 3/29/07, Grant Slade <grant.slade@xxxxxxxxx> wrote:
Sorry, I should have probably posted this at the Saxon forum.  I did
try your solution Mike -

FileOutputStream fos = new FileOutputStream(myfile);
transformer.transform(xmlStreamSource, new StreamResult(fos));
fos.close();

which still didn't work to delete the file  Not sure what the issue
is, maybe it's not something with Java.

However, I tried Pete's solution and it worked, the file doesn't get written:

ByteArrayOutputStream bos = new ByteArrayOutputStream();
StreamResult result = new StreamResult(bos);

transformer.transform(xmlStreamSource, result);
if(bos.size() > 0)
{
   bos.writeTo(new
FileOutputStream("./JournaltoGoogleXMLFiles/google." + an + ".xml"));
}
else
{
   return false;
}

On 3/28/07, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> As far as the spec is concerned the state of filestore is undefined after a
> transformation fails, so this is presumably intended as a Saxon-specific
> question rather than an XSLT language question. I would imagine that in this
> situation you have started serializing the output but the first buffer-full
> hasn't yet been flushed to disk at the time of termination. I've certainly
> seen this leave empty files on disk (if your transformation had got further
> it might have left a non-empty but incomplete output file), but I haven't
> seen problems in deleting such files; presumably the problem is that the
> process still has a connection open to the file. In your call you've created
> the FileOutputStream yourself, and Saxon takes the view that if you create
> the stream, then you should close it after use (Saxon will only close the
> stream when it has created it itself.) So it might be as simple a matter as
> closing the stream before attempting the file delete.
>
> Michael Kay
> http://www.saxonica.com/
>
>
> > -----Original Message-----
> > From: Grant Slade [mailto:grant.slade@xxxxxxxxx]
> > Sent: 28 March 2007 21:47
> > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> > Subject:  <xsl:message terminate="yes"> results in zero
> > byte file getting written
> >
> > When I use the following to transform a file:
> >
> > transformer.transform(xmlStreamSource, new StreamResult(new
> > FileOutputStream("F:\\myfile.xml")));
> >
> > If I have an <xsl:message terminate="yes"> in the xsl
> > stylesheet "myfile.xml" gets written but as a zero byte file.
> >
> > If I try and use Java to delete the file through the File
> > class, it won't delete it although it finds the file through
> > the exists() method.
> >
> > My question is, is there a way to either not have the file
> > get written in the first place, or is there a way to force a
> > delete of that file?

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.