[EMAIL PROTECTED] wrote:

Author: dandiep
Date: Tue Jun 12 15:49:08 2007
New Revision: 546656

URL: http://svn.apache.org/viewvc?view=rev&rev=546656
Log:

Refactoring of the low level IO layer inside CXF.

Remove the dependence on flush() being called ONCE and only once
inside CXF. There was the assumption in all the code that things would be cached until we actually finished databinding, which is a bad assumption. There are a couple problems with this: 1. The Soap envelope writer was writing the envelope twice if a fault was thrown during databinding and the stream was already flushed. (i.e. during
validation)
2. The code didn't differentiate between the type of caching that was going
on. i.e. are we a) writing to the underlying stream AND caching the message
at the same time. Or b) are we caching the message and then writing on close()

Ensure that the RM and Logging layers correctly do their work on close() instead of flush().
Transports now pass in the underlying stream. The RM layer and logging
interceptors correct detect when a cached stream is not being used
and act accordingly. This is much more robust as I/O transformations
are a very valid use case an many people will want to switch the underlying streams. We also shouldn't force transport writers to use CachedOutputStream.
Rename AbstractCachedOutputStream to CachedOutputStream and make
it a non-abstract class. This cuts down on the number of CachedOutputStream
classes laying around! There are now two extended implementations of
COS as well:
1. WriteOnCloseOutputStream. This caches the message until the outputstream
is closed. This is needed for the RM scenarios where we are caching the message
until the CreateSequence is done. We don't want to open the connection until
all of this is done. (I think we could probably reset this output stream as soon as the createsequence is finished though
Hi Dan,

I am not sure what you mean with 'caching the message until the CreateSequence is done': In the RM case the original application message should not be written before a Sequence is available - the logical RM out interceptor (which triggers sequence creation) sits in the PRE_LOGICAL phase RM uses the RetransmissionCallback class to cache application messages for future resends - util they are acknowledged.

Andrea.

2. CacheAndWriteOutputStream. This caches the message while it is written
to the underlying stream at the same time. Useful for logging.

Update the DataBinding code to have JAXB write directly to the OutputStream
whenever possible. This gives a great performance improvement for some 
scenarios.

Refactor the JAXB code so we don't have so many data readers/writers.

TODO: Make RM and Logging work when the message is larger than memory or the CachedOutputStream writes to disk. TODO: Fix HTTPS 401 Redirect test


----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Reply via email to