cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <>
Subject Re: svn commit: r546656 [1/2] - in /incubator/cxf/trunk: api/src/main/java/org/apache/cxf/io/ api/src/main/java/org/apache/cxf/message/ api/src/main/java/org/apache/cxf/phase/ common/common/src/main/java/org/apache/cxf/helpers/ rt/bindings/http/src/main/ja...
Date Wed, 13 Jun 2007 07:47:48 GMT wrote:

>Author: dandiep
>Date: Tue Jun 12 15:49:08 2007
>New Revision: 546656
>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
>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.


>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
View raw message