Hi Daniel,
thank you for your quick reply!

Yes, we close and consume the "main document" stream however we have
activated the LoggingInInterceptor and we have found that the soap response
from the server is a little bit "dirty". More in detail:

-  the multipart contains two parts: the soap envelope and the binary
content of the document. 
- in the soap body we have found there are two different elements with a
swaref element inside (one is unexpected). The first one references the
correct "content id" of the document. The second one instead references a
content id that doesn't exists.

Anyhow if we force a call to the method "getInputstream" and "close" of that
stream immediatly on the DataHandler of the "dirty" element, the file is
deleted :)

One last question: if a soap response contains more elements that reference
the same content id (the correct value not as as in our wrong response) is
it anyhow necessary to open and close the stream on every DataHandler also
if they references the same binary content -  file? Perhaps, may a custom
interceptor (that forces the closure of all attachments ) attached to a
opportune phase, help to mantain the code cleaner?

Thank you very much.
Stefano




--
View this message in context: 
http://cxf.547215.n5.nabble.com/Temporary-files-created-for-data-over-64kb-are-never-deleted-swaref-tp5738911p5738951.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to