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 [email protected] http://dankulp.com/blog Talend - http://www.talend.com
