On Wed June 24 2009 9:19:48 am Andrew Clegg wrote: > 2009/6/22 Daniel Kulp <[email protected]>: > > 2) Until you move up to 2.2.1 or 2.2.2, you aren't going to benefit from > > using a StreamSource anyway. In fact, it will be really problematic as > > it will go stream -> stax -> DOM -> stream for incoming and stream -> DOM > > -> stax -> stream on the outgoing. For 2.2.2, the incoming stays the > > same, but the outgoing will go directly stream -> stax -> stream. > > Does CXF *always* parse the stream to a DOM tree before delivering it, > even in 2.2.2? Is there no way to override this?
Depends on what needs to be delivered to the user. Internally, we create an XMLStreamReader which is what we use for parsing the SOAP parts of things. When we get to the SOAP:Body, it depends on the what is requested. For things like "normal" JAX-WS services that use JAXB objects, we just pass the XMLStreamReader directly into the JAXB unmarshallers and it spits out the JAXB objects. No DOM created. For "Provider" services, it depends on the type of provider. (I was slightly wrong on my first message in regards to this) For SAXSource and StreamSource, a "CachedOutputStream" is created and wrapped with an XMLStreamWriter and the XML stuff is copied from the XMLStreamReader into the writer and then a StreamSource or SAXSource is created from that stream. This is semi-low memory as the CachedOutputStream will cache in files on disk if it gets too large. However, it ends up parsing all the XML to copy it (and fix namespaces) and then passed as a stream to the app which, in general, then parses the XML again. Thus, it may have performance impact. If the Provider is marked just "Source" or "DOMSource", then it parses into a DOM and returns a DOMSource. This allows you to work with the DOM without reparsing. However, that's probably more memory intensive. Thus, it depends on whether you want memory intensive or CPU intensive. One thing I keep meaning to try getting to work is to allow Provider<XMLStreamReader> to get the raw XMLStreamReader that we use. That would provide the best performing and best memory usage scenario. It's just not working yet. -- Daniel Kulp [email protected] http://www.dankulp.com/blog
