Using the Source object in CxfPayload is get a better performance, but it could cause some trouble if you want to reread the Payload message again. I agree with you we need avoid the satiation that converted object have some side effects on CxfPayload body.
I will apply the patch shortly. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On February 25, 2015 at 5:12:19 PM, Siano, Stephan (stephan.si...@sap.com) wrote: > Hi, > > The CxfPayload data type (from camel-cxf) contains some stream elements but > does not > support stream caching. > > I am working on a contribution to provide stream caching for that. During > that if found > some strange things in the CxfPayloadConverter: > If the CxfPayloadConverter converts a CxfPayload into something else, it > might change > the original CxfPayload as a side effect. This is likely done in order to > make the CxfPayload > re-readable (because otherwise the Source containing the message body may get > lost > after processing). The code also contains a bug: if the body source is e.g. > converted > into a SAXSource the body source will be set to that SAXSource even if was > set to a (re-readable) > DOMSource before. I created CAMEL-8402 for that (the patch just removes two > lines of > code). > > In my optinion this side-effect of the type converter should not be there at > all. Do you > think it is ok if I remove the mechanism altogether when introducing a > StreamCache for > CxfPayload? The StreamCache will make sure that the CxfPayload is re-readable > without > these hacks. > > Best regards > Stephan >
