Project

Profile

Help

Compile: NotSerializableException

Added by Anonymous almost 20 years ago

Legacy ID: #2881743 Legacy Poster: vanfleet (vanfleet)

I’m getting NotSerializableException errors when I try to compile the following stylesheet: <xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="2.0" xmlns:File="java:java.io.File" xmlns:xps="http://www.ugs.com" exclude-result-prefixes="xps xs File" > <xsl:template match="topicSet"> </xsl:template> <xsl:function name="xps:getFileExists"> <xsl:param name="fileName"/> <xsl:variable name="exists" select="File:exists(File:new($fileName cast as xs:string))"/> <xsl:sequence select="$exists"/> </xsl:function> <xsl:function name="xps:getNumber"> <xsl:param name="theNode"/> <xsl:variable name="result"> <xsl:number level="any" select="$theNode" format="I" count="/topicSet/bodyTopics/part | /topicSet/appendixTopics/part"/> </xsl:variable> <xsl:sequence select="$result"/> </xsl:function> </xsl:transform> I’ve narrowed it down to the following: In the xps:getFileExists function the exception seems to come from the reference to the File class. I don’t understand why I’m getting this error, the documentation says that the compilation is based on Java serialization and the File class does implement Serializable. The error I’m getting is: java.io.NotSerializableException: java.lang.reflect.Constructor at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1224) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1050) : : In the xps:getNumber function the exception is coming from the <xsl:number> element. The error here is: java.io.NotSerializableException: net.sf.saxon.style.XSLNumber at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) : : Any Ideas? Thanks, dv


Replies (3)

Please register to reply

RE: Compile: NotSerializableException - Added by Anonymous almost 20 years ago

Legacy ID: #2883289 Legacy Poster: Michael Kay (mhkay)

Thanks for reporting this. As you suspected there are two separate problems. Firstly, xsl:number with the select attribute cannot be serialized because it incorrectly retains a reference to a class in the source stylesheet representation, which should have been discarded. Secondly, Java reflection objects (such as AccessibleObject) are not serializable, which means now that calls on extension functions are statically bound, stylesheets containing calls on extension functions cannot be compiled. I have added code to circumvent this limitation by customizing the serialization and deserialization of ExtensionFunctionCall objects. Both these problems will be fixed in the next release. Michael Kay

RE: Compile: NotSerializableException - Added by Anonymous almost 20 years ago

Legacy ID: #2884363 Legacy Poster: vanfleet (vanfleet)

Great! Thanks for your quick response (again). I was looking for a release schedule on your web site but I couldn’t find one. When do you expect the next release to be available? Thanks again, David Vanfleet

RE: Compile: NotSerializableException - Added by Anonymous almost 20 years ago

Legacy ID: #2884522 Legacy Poster: Michael Kay (mhkay)

I've always worked on the basis of releasing when the code looks ready for release, and avoiding any pressure to be date-driven, but with the aim of a release every three months or so. I think that an 8.2 before Christmas is possible, but if it's not looking stable enough then it will wait until January. Michael Kay

    (1-3/3)

    Please register to reply