Hi Stefano,
On 12/06/14 12:51, sfont wrote:
Hi Sergey,
thank you for your quick reply! :)
I have read the source code of the class LoadedByteArrayInputStream and
TransferableFileInputStream. Calling the "IOUtils.transferTo" method on a
instance of LoadedByteArrayInputStream creates a new file from the bytes in
memory. Instead calling that method on a TransferableFileInputStream try to
rename the file to another one and if the rename fails it does a new copy of
the file.
I also suspect that if the file is renamed the old temp referenced in
org.apache.cxf.io.CachedOutputStream not exists anymore and this may cause a
(not blocking) error trying to delete it in the method "deleteTempFile()"
that is called when we close the stream.
I would like to avoid an unnecessary copy/rename to a new file (e.g. for
byte array) and would like to find an alternative if possibile to let my
code to reopen the stream on the temporary file an arbitrary number of
times. Do you think that an interceptor calling:
org.apache.cxf.io.CachedOutputStream.holdTempFile()
on all attachments before processing (what phase?) the request in our
backend class and another interceptor after the response has been processed
may work?
For an example see a suggestion from Dan in the last post of a my old post:
http://cxf.547215.n5.nabble.com/Temporary-files-created-for-data-over-64kb-are-never-deleted-swaref-td5738911.html
"That definitely could would work. At the VERY VERY end of the in chain,
you could possibly grab the attachment list out of the message and just loop
through and close each one."
If Dan thinks it can work then sure, give it a try :-).
How will you get the temp files eventually deleted then ?
Cheers, Sergey
Thank you very much.
Stefano.
--
View this message in context:
http://cxf.547215.n5.nabble.com/Empty-stream-when-reading-twice-the-content-of-an-attachment-greater-than-100KB-tp5745031p5745052.html
Sent from the cxf-user mailing list archive at Nabble.com.
