我用JAX-WS RI编写了一个简单的上传服务。 XJC使用DataHandler
类生成类。在编码时,@MTOM
和@StreamingAttachment
被添加到服务实现中。现在,当客户端(.NET客户端)使用MTOM multipart/related
发送上载的数据并收到数据但数据处理程序中的数据源为com.sun.istack.ByteArrayDataSource
和java.io.ByteArrayInputStream
时。这意味着来自客户端的流完全被消耗到内存中。对于较大的文件,内存会爆炸。
经过一些谷歌搜索研究后,我没有找到任何关于SOAP处理程序的SO问题,但我没有。还没有成功。
我启动了一个调试会话并发现内部数据包含在StreamingDataHandler
中,这是建议的方式,但是MtomCodec
queries附件的长度并导致基础数据对象为fully consume the input stream into memory。故事结束。
这对我来说似乎已经死了,因为MTOM的整个优化已经完全消失了。
有谁知道这个解决方案?否则,JAX-WS RI中的整个方法似乎毫无用处,我不得不求助于REST。
这可能与MTOM not working when using SOAPHandler重复。结果是一样的。
对于它的价值,我在:
答案 0 :(得分:0)
在网上进一步调试会话和搜索后,我发现了几个JIRA问题和博客文章,它们在JAX-WS RI中很明显。只要你有一个处理程序,你就会丢失。这适用于传出流,尤其适用于传入流。
最后,JAX-WS RI 不可用用于文件交互。我必须在某个时候评估Apache CXF。