This is not a swaRef WSDL. It is Soap With Attachments and is purely an
artifact of WSD MIME binding and not represented in XML schema (unlike
MTOM and SwaRef). That would make it unsupported by JAXB IMO. For
further reference see the WS-I Attachments Profile
(
http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html), where this
MIME binding support is described.
-Simeon
Kohsuke Kawaguchi wrote:
> Dan Diephouse wrote:
>> Hiya,
>>
>> I'm looking for a way to use JAXB with a legacy WSDL which doesn't
>> use the
>> wsi:swaRef type. Here's what the message looks like:
>>
>> <wsdl:message name="echoDataRequest">
>> <wsdl:part name="text" type="xsd:string" />
>> <wsdl:part name="data" type="xsd:base64Binary" />
>> </wsdl:message>
>>
>> And my binding:operation:
>>
>> <wsdl:operation name="echoData">
>> <soap:operation soapAction="" style="literal" />
>> <wsdl:input>
>> <mime:multipartRelated>
>> <mime:part name="body">
>> <soap:body parts="text" use="literal" />
>> </mime:part>
>> <mime:part name="data">
>> <mime:content part="data" type="application/octet-stream" />
>> </mime:part>
>> </mime:multipartRelated>
>> </wsdl:input>
>> <wsdl:output>
>> <mime:multipartRelated>
>> <mime:part name="body">
>> <soap:body parts="text" use="literal" />
>> </mime:part>
>> <mime:part name="data">
>> <mime:content part="data" type="application/octet-stream" />
>> </mime:part>
>> </mime:multipartRelated>
>> </wsdl:output>
>> </wsdl:operation>
>>
>> Now the issue here seems to be that JAXB requires swaRef to read in an
>> attachment. On my incoming message I have this:
>>
>> <text>Hello</text>
>> <data href="cid:....."/>
>>
>> Is there any way to get JAXB to recognize that data is in fact an
>> attachment
>> without reworking my schema?
>
> Hmm. I don't think it works. As far as JAXB can tell, @href is just
> invalid and it will simply ignore that, and consider "" to match
> bas64Binary, hence length-0 binary data.
>
> Did some spec at point advocated this kind of swaRef support? If so,
> we can consider handling this. But if this is invented by this
> particular appliation, I don't think we can afford to handle such cases.
>