Brian, Just to be clear, I don't think binary compatibility across different versions is all that useful or pragmatic. I was under the impression that version compatibility was a requested feature from another user. My use case for needing to serialize templates arises from a large set of XML documents that need to be transformed, styled, and annotated with other XML documents. The business logic for this takes place in 3 stateless EJB beans. The XSLT templates are also self-feeding and can be generated as a result of another transformation. The EJBs use a caching algorithm to keep references the XSLTs because some are expensive to piece together and may even originate from an external (unreliable) network. The first-hit cost of creating and compiling the templates is acceptable as long as future requests are speedy. My concern is that if the templates are no longer serializable, I will have to recreate the XSLTs every time the bean is activated. I can verify that passivation/activation occurs fairly often for stateless beans because I've tried tweaking the Borland Enterprise Server settings to optimize the ready pool.
My thoughts were along the lines that if serialization is too slow, it may be possible to use the serializer framework to serialize the DTM that represents the templates object. I don't imagine such an undertaking would be easy, but would potentially kill several birds with one swoop by allowing serialization across versions, reuse of dtms for multiple transforms, and increased serialization performance of templates. I'd being willing to look into what would be required to make such a change. Maybe someone familiar with the XPath implementation could point out how the document() functionality is implemented before I lose any more hair trying to trace the code. If a more robust/speedy serialization of templates is not a priority or overly complex, I would vote for leaving templates marked as serializable and let the user deal with the versioning issue. John Meyer Senior Software Engineer Clinician Support Technology 1 Wells Avenue, Suite 201 Newton, MA 02459 www.cstlink.com -----Original Message----- From: Brian Minchau [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 02, 2004 1:53 AM To: [EMAIL PROTECTED] Subject: RE: Removing Serializable from Templates implementations 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: [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]
