Greetings, I would have to say that I disagree with the recommendation to remove the Java serialization capability from the templates implementations. My reasons are as follows:
Firstly, the ability to serialize objects for short term storage is a key design factor of EJB. All session bean class members should be serializable. If not, the bean must be able to serialize the member and its state to a stream and reinitialize the objects later. This is known as passivation and activation respectively. If the templates object is generated from a network source, the XML source will need to be retrieved from the network and introduces an additional point of failure. Also, the compilation of an XSLT requires a not insignificant amount of contextual information such as base URI, URI resolver, and system properties. To ensure a completely accurate serialization, all of this information be preserved. Currently Xalan does this intrinsically within its implementation and object graph serialization. With regards to the versioning issues, I thought it is generally understood that standard Java object graph serialization is not compatible with future versions of the object. The Java Swing 1.4.2 API documentation states this limitation as follows: Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeans(tm) has been added to the java.beans package. Please see XMLEncoder. I think Xalan should adopt a similar warning to the Templates implementation. Finally, the performance and versioning issues mentioned can be overcome by implementing the readObject and writeObject functions to serialize the templates object in a more succinct manner. Given the issues with the use of the document() function to access the current xslt source, it may be possible to use the xslt source DTM to serialize the xsl source document(s) and simply reparse them later. I don't know how feasible this strategy is, as I could not locate the document() functionality within the org.apache.xpath classes (It is notably missing from org.apache.xpath.compiler.FunctionTable). I really don't relish the possibility of having to implement all that serialization functionality in our EJBs if this change goes through. Comments or suggestions? John Meyer Senior Software Engineer Clinician Support Technology 1 Wells Avenue, Suite 201 Newton, MA 02459 www.cstlink.com -----Original Message----- From: Henry Zongaro [mailto:[EMAIL PROTECTED] Sent: Monday, May 31, 2004 8:54 PM To: [EMAIL PROTECTED] Subject: Removing Serializable from Templates implementations Hello. The Xalan-J Interpretive processor and XSLTC both implement the Serializable interface on the classes that implement the Templates interface: StylesheetRoot and TemplatesImpl, respectively. Recently, someone pointed out via direct e-mail that we've broken the ability to deserialize a Templates object with Xalan-J 2.6 that was serialized using version 2.5.2 of Xalan-J Interpretive. After a little investigation, Brian Minchau found that we've repeatedly broken the ability to serialize a Templates object with one version Xalan-Java Interpretive and deserialize with another, and many releases of XSLTC have been completely unable to serialize a Templates object. It's not entirely clear what benefit Java serialization provides in the case of a Templates object. Members of the Xerces-J team recently performed a test of Java serialization and deserialization on a DOM tree, and found that parsing an XML document into a DOM tree, and serializing that DOM as XML was much faster. Given the similar level of complexity between DOM trees and Templates objects (at least in the case of the interpretive processor), I suspect we'd find similar results with serializing and deserializing Templates objects. Given that we've had so much breakage with serializing and deserializing Templates objects, and given that JAXP has no requirement that a Templates object implement the Serializable interface, I'd like to propose that we remove Serializable from the Templates object graphs for objects returned by TransformerFactory.newTemplates(). However, given that this might be controversial, I wanted to raise it for discussion in the mailing list before putting it to a vote. Thanks, Henry ------------------------------------------------------------------ Henry Zongaro Xalan development IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044 mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- 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]
