Raymond, > IMHO, the XMLStreamWriter is a simple way to produce XML documents by > writing xml artifacts instead of string concation. For SDO, we already have > XMLHelper.save(). What's the add-on value to go through the XMLStreamWriter > layer? Can something take advantage of the result XMLStreamWriter?
One of the things Celtix/IONA is doing is creating "custom" XMLStreamWriters that output to things other than XML. One example that the apache Yoko project is doing is to output to CORBA DynType things for making CORBA invokations. The yoko project, in combination with the celtix binding in Tuscany, should allow tuscany apps to invoke on CORBA applications. However, that would need the XMLStreamWriter (maybe XMLEventWriter) stuff working. Dan > > Thanks, > Raymond > > ----- Original Message ----- > From: "Daniel Kulp" <[EMAIL PROTECTED]> > To: <[email protected]> > Cc: "Raymond Feng" <[EMAIL PROTECTED]> > Sent: Wednesday, June 07, 2006 1:36 PM > Subject: Re: XMLStreamHelper > > > Raymond, > > > >> 1) What's the use case to save a XMLDocument or DataObject to the > >> XMLStreamWriter? If there's no such requirement, we can get rid of them. > > > > Well, part of the work we are doing in Celtix is to allow the > > "databinding" > > layer to write directly toward a XMLStreamWriter. I was hoping to use > > those > > methods since that is ideal. > > > >> 2) With the createStreamReader() method, we can easily pipe the reader > >> to writer with a utility (Axiom has one). Here's the implementation in > >> my latest patch. > >> > >> XMLStreamReader reader = createXMLStreamReader(document); > >> new XMLStreamSerializer().serialize(reader, writer); // > >> XMLStreamSerializer is the utility to pull events from the reader and > >> dump > >> them into the writer > > > > What is the performance impact of doing that? I'm OK with doing > > something > > like that (and maybe even making the mentioned save() and saveObject() > > methods do that) if there isn't a major performance issue with doing > > that. > > > > Basically, the goal is to get the objects written out to a stream as > > quickly > > as possible. If "reading events from one stream and pumping them to the > > output stream" isn't too bad, I'm OK with it. But if there is a > > performance > > impact of doing that, then I would suggest leaving the ability to write > > directly to the XMLStreamWriter. > > > > Thanks! > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727 C: 508-380-7194 F:781-902-8001 > > [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
