Unmarshaling jaxb error from web service using MTOM

Question

I have a jax-ws web service using a schema based payload. Adding MTOM Binding Type:

<xs:element name="Attachment" type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream" minOccurs="0" maxOccurs="1" > </xs:element> 

The ws-import generated java file looks right:

 @XmlRootElement(name = "Contact") public class Contact { @XmlElement(name = "Attachment") @XmlMimeType("application/octet-stream") protected DataHandler attachment; 

Using soapUI to send a request.

HTTP headers:

  Accept-Encoding: gzip,deflate Content-Type: multipart/related; type=application/xop+xml; start=< [e-mail] >; start-info=text/xml; boundary=----=_Part_96_20541990.1485816424570 SOAPAction: http://hsn.us.banner.hsntech.com/Level1Request MIME-Version: 1.0 Content-Length: 47624 [1]: https://i.stack.imgur.com/BEbZS.jpg 

Then view the HTTP part with the encoded file section:

 ------=_Part_96_20541990.1485816424570" Content-Transfer-Encoding: binary" Content-ID: <test1.jpg>" Content-Disposition: attachment; name="test1.jpg"; filename="test1.jpg"" [0xff][0xd8][0xff][0xe0][0x0][0x10]JFIF[0x0][0x1][0x1][0x1][0x0]`[0x0]`[0x0][0x0][0xff][0xdb][0x0]C[0x0][\n]"... etc... 

But keep getting this error:

 [Exception [EclipseLink-25004] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.XMLMarshalException&#xd; Exception Description: An error occurred unmarshalling the document&#xd; Internal Exception: java.lang.IllegalArgumentException: MjAxNi0wMS0wNVQwOTowMDowMA==]</faultstring></ns0:Fault></S:Body></S:Envelope> 

Any suggestions?

Answer 1

The error message basically states that the value MjAxNi0wMS0wNVQwOTowMDowMA== is illegal. If you check it, this is base64 date:

 2016-01-05T09:00:00 

I do not know if there is another field in the object you are trying to undo. But in case the unmarsall process is not capable of processing base64 encoded (base) values. You should check if any adapter is needed.

In one sentence: You should probably have a base64 decoder or check the original service, since the decoded String is actually not some binary data.

(If you insert all the codes used, I can take a deeper look at it.)