I did'nt have the OOM before juste because :
My source is a JaxB Object with a DataHandler, this one is Annoted with
@XmlMimeType and @XmlAttachmentRef. So the DataHandler is used correctly.
When the JaxWS Handler transform it an a SAAJMessage, the attachment use the
DataHandler yet. It's when the codecs want to write the attachment to the
outputStream (MimeCodec and MTOM codec) the SAAJAttachment load all the data
in a byte array, in the write to method.
2011/8/9 Dmitry Katsubo <dma_k_at_mail.ru>
> On 08.08.2011 11:36, yann.blazart_at_gmail.com wrote:
> > Hi ! As I ve no responses, I'm writing to the list.
> >
> > I have open a bug http://java.net/jira/browse/JAX_WS-971. As nobody
> > take it, I've writed a post on the forum, but no more response...
> >
> > So, when you modify an outcome message with a Handler, and when you
> > deal with large attachment,you have a problem, because in the classe
> > com.sun.xml.ws.message.saaj.SAAJMessage.SAAJAttachment, we have the
> > following method used by MimeCodec and MTOMCodec :
> >
> > public void writeTo(OutputStream os) throws IOException {
> > os.write(asByteArray());
> > }
> >
> > The document is entirely mounted in memory !
> >
> > Is anybody can make a patch to correct this ?
>
> Strange, that you haven't got OutOfMemory before (or you still haven't
> got it?).
>
> Tracing back the source:
>
> SAAJMessage.SAAJAttachment -> AttachmentPartImpl -> MimeBodyPart, and
> then in constructor we have a choice:
>
> (a) SharedInputStream: Can somehow clone the contents (e.g. in case the
> attachment was saved to file / temporary location)
> (b) any other: ByteOutputStream is created (the contents is completely
> in memory).
>
> As SharedInputStream has no implementors, see also the code comment:
>
> // SAAJ doesn't utilize this, but I think it should.
>
> so I suppose (b) is the common case which means attachments are always
> stored in memory.
>
> --
> With best regards,
> Dmitry
>