cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Using CachedOutputStream insted of byte[] in WS-RM
Date Tue, 22 Mar 2011 00:55:53 GMT
On Monday 21 March 2011 8:48:56 AM Aki Yoshida wrote:
> Hi,
> In working on the issue to remove the byte array from RMMessage
> (CXF-1100), I changed RMMessage to use CachedOutputStream instead of
> the byte[]. I understand that there will be an additional change
> required in the future to move the persistence before the WS-Security
> processing step so that the security processing can be applied later
> at each retransmission. I think the change that I made will be
> transparent to this future change and will not make this future change
> more difficult.
> 
> I can attach the patch file to CXF-1100, but I have a few questions
> that I would like to have your opinions.
> 
> In short summary, the changed that I made are:
> - RMMessage holds an instance of CachedOutputStream instead of the byte
> array. 

Makes sense.

> - added some methods to RMMessage to work on InputStream and
> CachedOutpuStream 
> - The temporarily saved content in message (stored with key
> RMMessageConstants.SAVED_CONTENT) is changed to an instance of
> CachedOutputStream and not of the byte array.
> - RetransmissionQueueImpl, RetransmissionCallback, RMManager,
> RMTxStore are changed accordingly.
> - The relevant test cases updated and added additional test cases for
> the cached out cases.

Cool.   Test cases are good.  :-)

> 

> Questions
> 1. RMMessage has setContent(byte[] c) and byte[] getContent(). I don't
> know what I should do with these methods. I modified them to use
> CachedOutputStream internally so that they work fine but marked them
> as deprecated. Should I handle these methods differently? The options
> can be:
>  - do not mark the methods as deprecated
>  - use internally a byte array and hold the array in RMMessage if
> these methods called (i.e., either one of the attributes is active)

For 2.4, I'd just remove them if they are no longer needed.  We can create a 
section in the Migration guide to cover RM internal changes.   This type of 
change would not affect 99% (or higher) of the users out there.


> 2. The test cases for cached out cases (i.e., CachedOutputStream
> caching out the data in a temporary file) are done by setting the
> property org.apache.cxf.io.CachedOutputStream.Threshold to a very
> small number (16) while using the standard test case data. I hope this
> is okay. I think making a test case to use a physically large data is
> not practical.

That's fine.  I think we do that in a couple other places as well.   For unit 
tests, just make sure you reset it back during cleanup.

> 3. I added getSourceSequence/getDestinationSequence in RMTxStore.
> However, these methods are not related to this RMMessage change but
> for another potential issue that I mentioned some days ago in this
> list. Should I keep these methods as the existence of these methods do
> not interfere with anything or should I remove them before creating a
> svn diff onRMTxStore for this issue?

Feel free to keep them.    I'm always of the "keep moving forward whenever 
possible" mindset.   Again, mark it in the migration guide.

Thanks!

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Mime
View raw message