Hi Paul ! Thanks for the suggestion. I found out that the actual class of the object returned after parsing an xml file is of type ' com.ibm.xml.dom.DeferredDocumentImpl ' This class extends from ' com.ibm.xml.dom.DocumentImpl ' which implements an interface called 'Document'. Whole of the traversal funtionality of a DOM object can be accessed if the handler is of type 'Document' to a object of class ' com.ibm.xml.dom.DeferredDocumentImpl ' returned by an parser like 'com.ibm.xml.parsers.NonValidatingDOMParser' As u suggested i can't serialize an Interface like 'Document' so i tried extending a class of my own from ' com.ibm.xml.dom.DeferredDocumentImpl ' but it didn't seem to work out as the constructor of the class requires a parameter which i can't supply being out of package class inhertance. Acutally it requries an 'ParserState' class object which in turn requires an 'XMLParser' class object which can't be instantiated as its an abstract class. Looking at the complexity i tried to serialize the object by casting it into ' com.ibm.xml.dom.DocumentImpl ' and receiving it in the same type of variable.
But as usual it doesn't seems to work as the error which keeps on coming is of the form of type EOFException here is the dump of the error : java.io.EOFException at java/io/DataInputStream.readUnsignedByte at java/io/DataInputStream.readUTF at java/io/DataInputStream.readUTF at java/io/ObjectInputStream.readUTF at java/io/ObjectStreamClass.read at java/io/ObjectInputStream.readClassDescriptor at java/io/ObjectInputStream.checkSpecialCases at java/io/ObjectInputStream.readObject at com/ms/!!!Internal_Class_0.DefaultReadMethod at java/io/ObjectInputStream.invokeDefaultReadObject at java/io/ObjectInputStream.defaultReadObject at java/io/ObjectInputStream.readNewObject ...... .... NOTE : ( very long list here ) .. at com/ms/!!!Internal_Class_0.DefaultReadMethod at java/io/ObjectInputStream.invokeDefaultReadObject at java/io/ObjectInputStream.defaultReadObject at java/io/ObjectInputStream.readNewObject at java/io/ObjectInputStream.readObject at com/ms/!!!Internal_Class_0.DefaultReadMethod at java/io/ObjectInputStream.invokeDefaultReadObject at java/io/ObjectInputStream.defaultReadObject at java/io/ObjectInputStream.readNewObject at java/io/ObjectInputStream.readObject at DaytimeApplet.getDOMUsingHttpObject at DaytimeApplet.refresh at DaytimeApplet.start at com/ms/applet/AppletPanel.securedCall0 at com/ms/applet/AppletPanel.securedCall at com/ms/applet/AppletPanel.processSentEvent at com/ms/applet/AppletPanel.run at java/lang/Thread.run
I feel that due to the big data structure there is a abrubt end of file being send by the server , i mean a kind of time out. The xml file i m parsing is quite big (181 KB) I tried to set the content length of the HttpServletResponse object in the Post method but for no use. What do u think ? I didn't send this mail to the mailing list as there were objections regarding the same Hope to have some advice on this . I may send u the code if need be! Thanks once again Rahul Goyanka firstname.lastname@example.org
----- Original Message ----- From: "Paul Wheaton" <email@example.com> To: <firstname.lastname@example.org>; "Java Prep-Java" <PrepTalk-Java@topica.com> Sent: Wednesday, January 26, 2000 9:36 PM Subject: Re: DOM object not serializable !
> > I tried to put the document object in an another class which > > I implements serializable interface (kind of making a data structure), > > and then tried to send the object of this class to the applet but that > > was also not successful. I just gives a very very long list of > exceptions > > in reading the object in the Java console of the Browser.(ie 5.0) > > Inherit the non-serializable object and make your new thing serializable. > > DOM is a set of interfaces, not actual classes, so DOM isn't to blame. > It's the implementation of DOM that is to blame. > > Side note: I take it that there isn't a problem asking non-cert questions > here? > > > > ===== > . > > > Prepare for Java Certification at www.javaranch.com > > > .
I think there's a conflict of intent here. XML and Serialization are two alternative ways to achieve the same end (a portable representation of an object graph). DOM is specifically a way of representing an arbitrary XML document as "live objects" in memory. The intention is that XML is read into a DOM structure, used/modified and then optionally written out to XML again. If you wish to use the data somewhere else, transfer it as XML. If you wish to use the data loaded into DOM for some other purpose, the intention of XML is that you traverse the DOM structure and build up your own alternative data structure, which can then be Serializable if you wish. If you find that this is all you are using DOM for, then the SAX API might be a better fit. SAX is an XML API designed for reading XML documents into a user-specific data structure rather than the generic and somewhat heavyweight DOM. Essentially, though, I would think hard about why you need to make this sort of XML/Serialization gateway. This is a fairly specific sort of software component which shouldn't be needed in many applications.