Thank you, it's starting to make more sense now. -----Original Message----- From: Andreas Delmelle [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 10:12 AM To: fop-users@xmlgraphics.apache.org Subject: Re: FOP Report - Exception thrown "Encoded String Too Long"
On Sep 30, 2008, at 19:04, Andreas Delmelle wrote: > On Sep 30, 2008, at 18:48, Johnston, Scott wrote: > > Hi > >> We are upgrading an application from Java 1.4 to 1.5 that uses FOP >> (v 0.93) (and subsequently an XSL transform). In the upgrade, the >> FOP report fails with the following stack trace: >> >> java.io.UTFDataFormatException: encoded string too long: 81879 bytes >> at >> java.io.DataOutputStream.writeUTF(DataOutputStream.java:347) >> at >> java.io.DataOutputStream.writeUTF(DataOutputStream.java:306) >> at >> com.sun.org.apache.bcel.internal.classfile.ConstantUtf8.dump >> (ConstantUtf >> 8.java:121) > > > Seems like a limitation of Sun's DataOutputStream that Sun's > internal Xalan-fork does not take into account... Small addition: the explanation is probably that Sun's internal Xalan prefers XSLTC, and wants to convert the stylesheet to a Java Class. There are limits to the length of a single source file in Java. Another route to try, if you don't want to (or cannot) switch the XSLT processor, could thus be to try and divide the single huge stylesheet into multiple smaller ones (linking them together by means of xsl:include or xsl:import). I'm not an expert in XSLTC, but this may suffice to trigger the generation of multiple smaller Java classes, instead of one monolithic one. HTH Cheers Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
