Thanks for the response.
That seems weird, though. That means if you call the serialize function
(without the cache), the OMDocument can effectively be corrupted.
I found myself putting this comment on OMDocument.serialize()
* <p>Caution: Serializing without caching means that any portion of
the document
* that has not been read will no longer be available for further
reading.
* In other words, this function can corrupt the remainder of your
<code>OMDocument</code>.
* Only use it when you're sure you know longer need the contents of
the document.</p>
Should the function also somehow mark the document then, so that
OMDocumentImpl.buildNext() throws an exception?
-Eric.
Davanum Srinivas wrote:
Hehehe...i asked the same question #1 last week when i met Eran in
Synapse F2F. Eran, Please check if my understanding below is correct.
Suppose you are building an om structure by reading stuff from a
stream and you are half-way through it you want to serialize
everything (including the stuff for which OM has not been built in
memory) then you can call serialize. So AFTER you serialize you lose
the info for which om was not built already. So if you want to build
the OM *AND* serialize the input to output, then you call
serializeWithCache.
Need to check on #2
-- dims
On 9/30/05, Eric Johnson <[EMAIL PROTECTED]> wrote:
I've got two OM questions at the moment:
1) What the heck does "OMNode.serializeWithCache()" mean? How is it
different from "OMNode.serialize()"? I was hoping to put some Javadoc
on the function(s) but couldn't figure out from inspection what the
substantive difference was.
2) What is the OMText "optimized" property? It is never set via
"setOptimized", and never inspected via "isOptimized." I'm guessing
that this was meant to be the "optimized" part of MTOM, but since it is
never set or used, is it worth keeping?
-Eric.
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
