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. - 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. 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) 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. 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? Thanks. Regards, Aki
