cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Flush Problem with HTTPCondit
Date Thu, 21 Sep 2006 15:02:53 GMT
Li, Tao (Tom) wrote:

>Hi Dan,
>
>If there's transforming interceptor, it must use a stream which can cache all the data
generated by other interceptor before it doing its transforming work, so our api providing
a AbstractCachedOutputStream to enable caching, and provide some callback like doFlush &
doClose for customization, and I think the AbstractCachedOutputStream can serve as a base
class for output stream used by transforming interceptor. 
>  
>
I don't think thats true. I could create a piped stream which unzips the 
data as I pull it through. There is no requirement that it be cached 
before I can unzip it as far as I know.

>That means even if there's do have transforming interceptor, the assumption won't caused
problem. And like Eoghan said, I will try to modify the AttachmentOutInterceptor to act like
a transforming interceptor, and provide a customized outputstream inherited from AbstractCachedOutputStream
whose doFlush() will only flush the underlying stream, the resetOut will be left to doClose().
>
>Any comments are welcomed!
>
>Thanks,
>Tom
>
>
>
>-----Original Message-----
>From: Dan Diephouse [mailto:dan@envoisolutions.com]
>Sent: Thursday, September 21, 2006 7:37 AM
>To: cxf-dev@incubator.apache.org
>Cc: Li, Tao (Tom)
>Subject: Re: Flush Problem with HTTPCondit
>
>
>Dan Diephouse wrote:
>
>  
>
>>Glynn, Eoghan wrote:
>>
>>    
>>
>>>Hi Tom,
>>>
>>>Well the current Conduit/CachedOutputStream model assumes that when the
>>>first flush() call is made during the outgoing interceptor chain
>>>traversal, the message content is effectively "frozen" in the sense that
>>>it can written onto the "real" output stream provided by the transport
>>>layer.
>>>
>>>Currently, as you say, this first flush() normally occurs in the
>>>SoapOutInterceptor after it has written the message body. However, I was
>>>thinking that in the normal case (i.e. in the absence of
>>>payload-transforming interceptors like Gzip) that we should change this
>>>so that the initial flush() occurs before the envelope is written (so
>>>that the SOAP envelope is streamed directly onto the wire, to avoid the
>>>overhead of caching and copying).
>>>
>>> 
>>>
>>>      
>>>
>>+1 - although, why not have the tranforming interceptors add the 
>>cached stream themselves if they need it as opposed to adding it at 
>>the transport level?
>>    
>>
>
>One other thing - I've seen some places in the code where people just 
>assume that its a cached outputstream (like the attachments code). This 
>is BAD, as there could be a transforming interceptor in between and it 
>could set its own outputstream. So it seems like we shouldn't make this 
>assumption at all anyway - in which case I'm not sure there is a reason 
>for it to be at the transport level. What do you think?
>
>- Dan
>
>  
>


-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message