RE: Removing Serializable from Templates implementations

[John Meyer <jm...@cstlink.com>]

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:zongaro@ca.ibm.com] 
Sent: Monday, May 31, 2004 8:54 PM
To: xalan-dev@xml.apache.org
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:zongaro@ca.ibm.com

---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org

RE: Removing Serializable from Templates implementations

[Brian Minchau <mi...@ca.ibm.com>]

John,
certainly not having binary compatibility of serialized Templates objects
from one release to another would make Xalan development much easier.  If
things had to be binary compatible from release to release then the inner
workings of the Templates (and things they directly or indirectly reference
in the graph of objects that would get serialized) would be fixed, and
development could grind to a halt because the inner workings of a class
(even private fields) could not change.

You are correct that writeObject and readObject and a few other things
could be done to make binary compatibility "better" but I don't think that
all problems can be overcome with this, and this is potentially quite a bit
of work.  It isn't enough to check that one can serializer one version,
de-serialize with another, it needs to actually work. Isn't most of benefit
here serializing/de-serializing with that same version of Xalan?  If binary
compatibility was free to break between releases (like Java Swing) then we
wouldn't even need to write writeObject/readObject methods.

I'm curious to know the business scenario where an EJB has a reference to a
Templates object that needs to be serialized. If one uses XSLT to generate
HTML from XML then that is presentation information and should be done in a
servlet, not in an EJB.  Entity EJBs are for hardened objects that you
don't want to loose (like a banking transaction), so I can't imagine an
entity bean having a Templates object. Stateless EJBs are basically are
there just to run other beans (like take money out of one account, an
entity bean, and put it into another) but provide an environment for
atomicity (all or nothing) and other robustness. I don't think that
stateless beans are passivated or activated.

The only thing left are stateful session beans. A stateful session bean
would hold a customers state from one use of the site to another. Are these
are the ones that I think you are writing about with regards to passivation
and activation.  These sort of beans hold things like your shopping cart of
things that you haven't quite purchased yet.  I presume that your stateful
EJBs are not generating HTML, but some other business logic?  Perhaps
transforming XML into other XML for business communcation?  I'm just trying
to understand the scenario where an EJB passivates a Template as part of
its state.



Regards,

----------
Brian Minchau
XSLT Development, IBM Toronto
e-mail:        minchau@ca.ibm.com


---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org