cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
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 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.


Daniel Kulp
Talend -

View raw message