Skip to main content

JAX-WS 2.1.7 with SOAPMessageHandler consumes the attachment

Please note these forums are being decommissioned and use the new and improved forums at
3 replies [Last post]
Joined: 2009-01-16

Hi all,
I'm using JAX-WS RI 2.1.7 (server and client side) to implement some fileUpload like web service.
The uploaded file must go straight to a database storage (no temporary file can be created). Together with the attachment, some "parameters" are passed in the SOAP body.
The SOAP message is signed (using WS-Security) but not the attachment (a digest of the attachment is present in the SOAP body to ensure integrity). The content type of the attachment is application/octet-stream. On the WS endpoint I have access to a DataHandler that I use to stream the file content to some DatabaseOutputStream.
The issue is that when I activate the SOAPMessageHandler (using the @HandlerChain annotation on the WebService endpoint) to implement my WS-Security algorithm, the whole attachment get's consumed (fully loaded in memory or written to the disk based on the values of the @StreamingAttachment annotation). As I can't afford having temporary files created (for confidentiality reason) the following values are specified : parseEagerly = false, memoryThreshold = -1L . Even with an empty implementation in the SOAPMessageHandler (not even doing a SOAPMessageContext.getMessage() call) I have the same behavior.
Is there a way to have access to the SOAP message in a handler without consuming the attachment ? My attachment can be up to 250 mb and this cause OutOfMemory errors in the server (increasing the max heap size is not acceptable since there can be multiple transfers in parallel)

Thanks a lot for your answers.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-06-01

It should not do without the SOAPMessageContext.getMessage() call. It is fixed in JAX-WS 2.2.1. Can you try with latest JAX-WS 2.2.2 nightly.

Joined: 2009-01-16

indeed it does not consume the attachment without the call to getMessage() (I was wrong for that).
But this does not solve my issue that is : I can't load the full attachment in memory and I can't write it to the disk. I have an OutputStream sub class that I can use to directly write the attachment to my database storage. But I can't use it, since the getMessage() call consumes it.
Do you have any idea to this issue ?
For testing purpose, I changed the readAsSoapMessage function in AbstractMessageImpl to ignore the attachments and everything works fine (my security stack does not check the attachment integrity directly). This works but is not really a clean solution. A prefered solution might be to tell to the MIMEPull apis that I want them to write to my OutputStream instead of to the default FileOutputStream.
Any help on this topic will be appreciated.
Thanks a lot already for you answer.


Joined: 2012-08-16

Hi gastush,

I am having trouble with exactly the same problem. I have been trying to find a solution and have come across your post. Were you able to solve this problem? How did you handle it?