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/m

[Dan Diephouse <da...@envoisolutions.com>]

I recall there being some scenario when I was debugging where I the
application message had already opened a connection on the wire while a
CreateSequence was being sent. Looking back I can see that this might have
been related to my refactoring at some point.

The big issue though was that things depended on having onFlush() called
once and only once.

- Dan

On 6/13/07, Andrea Smyth <an...@iona.com> wrote:
>
> dandiep@apache.org 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
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog