cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Using CachedOutputStream insted of byte[] in WS-RM
Date Mon, 21 Mar 2011 12:48:56 GMT
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.

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 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?

Regards, Aki

View raw message