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.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com