You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by André Szdzuy <as...@axway.com> on 2007/08/30 15:39:42 UTC
wrong WSDL generated for MTOM attachments
Hi,
I am providing a web service based on servicemix-jsr181 and a POJO. My
operation has a parameter "TARFILE" of type DataHandler and I have MTOM
enabled. The parameter part of the WSDL generated by servicemix-jsr181 looks
like this:
<xsd:element minOccurs="0" name="TARFILE" nillable="true"
type="xsd:base64Binary"/>
If I import the WSDL with some other SOAP tool like SoapUI and generate a
SOAP request from it the parameter TARFILE is considered to contain a base64
string and not a reference to an attachment as I actually want. SoapUI's
behaviour is correct, I would say, because the WSDL doesn't contain any hint
that MTOM and attachments should be used.
When I adjust the WSDL manually by replacing "xsd:base64Binary" by
"xmime:base64Binary" with xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
then SoapUI generates the correct SOAP request from it!
Can I configure the WSDL generation so that it puts "xmime:base64Binary"
into the WSDL? Or is it a bug in servicemix-jsr181 or even XFire?
Thanks for your help...
André
--
View this message in context: http://www.nabble.com/wrong-WSDL-generated-for-MTOM-attachments-tf4354339s12049.html#a12407460
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: wrong WSDL generated for MTOM attachments
Posted by Freeman Fang <fr...@iona.com>.
Hi Andre,
Seems your generated wsdl missing
xmime:expectedContentTypes="application/octet-stream
It should be
<xsd:element minOccurs="0" name="TARFILE" nillable="true"
type="xsd:base64Binary"
xmime:expectedContentTypes="application/octet-stream/>
I am not expert of xfire, which jsr181 se based on,
Since cxf is merged from xfire, so I guess what we do it in cxf is
helpful for you. To generate right wsdl, basicaly you need create a
wrapper bean for your DataHandler and add jaxb annotation
@XmlMimeType("application/octet-stream") , something like
@XmlType
public class Picture {
private String title;
@XmlMimeType("application/octet-stream")
private DataHandler imageData;
public String getTitle() { return title; }
public void setTitle(String title) { this.title = title; }
public DataHandler getImageData() { return imageData; }
public void setImageData(DataHandler imageData) { this.imageData = imageData; }
}
And you can get more details from
http://www.nabble.com/MTOM-sample-generated-WSDL-with-DataHandler-on-server-t4210895.html
Best Regards
Freeman
André Szdzuy wrote:
> Hi,
> I still have this problem... Doesn't anyone have an idea?
> At least I would appreciate a hint if it's rather a bug of servicemix-jsr181
> or XFire.
>
> Thanks
> André
>
>
>
> André Szdzuy wrote:
>
>> Hi,
>> I am providing a web service based on servicemix-jsr181 and a POJO. My
>> operation has a parameter "TARFILE" of type DataHandler and I have MTOM
>> enabled. The parameter part of the WSDL generated by servicemix-jsr181
>> looks like this:
>>
>> <xsd:element minOccurs="0" name="TARFILE" nillable="true"
>> type="xsd:base64Binary"/>
>>
>> If I import the WSDL with some other SOAP tool like SoapUI and generate a
>> SOAP request from it the parameter TARFILE is considered to contain a
>> base64 string and not a reference to an attachment as I actually want.
>> SoapUI's behaviour is correct, I would say, because the WSDL doesn't
>> contain any hint that MTOM and attachments should be used.
>>
>> When I adjust the WSDL manually by replacing "xsd:base64Binary" by
>> "xmime:base64Binary" with xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
>> then SoapUI generates the correct SOAP request from it!
>>
>> Can I configure the WSDL generation so that it puts "xmime:base64Binary"
>> into the WSDL? Or is it a bug in servicemix-jsr181 or even XFire?
>>
>> Thanks for your help...
>>
>> André
>>
>>
>>
>
>
Re: wrong WSDL generated for MTOM attachments
Posted by André Szdzuy <as...@axway.com>.
Hi,
I still have this problem... Doesn't anyone have an idea?
At least I would appreciate a hint if it's rather a bug of servicemix-jsr181
or XFire.
Thanks
André
André Szdzuy wrote:
>
> Hi,
> I am providing a web service based on servicemix-jsr181 and a POJO. My
> operation has a parameter "TARFILE" of type DataHandler and I have MTOM
> enabled. The parameter part of the WSDL generated by servicemix-jsr181
> looks like this:
>
> <xsd:element minOccurs="0" name="TARFILE" nillable="true"
> type="xsd:base64Binary"/>
>
> If I import the WSDL with some other SOAP tool like SoapUI and generate a
> SOAP request from it the parameter TARFILE is considered to contain a
> base64 string and not a reference to an attachment as I actually want.
> SoapUI's behaviour is correct, I would say, because the WSDL doesn't
> contain any hint that MTOM and attachments should be used.
>
> When I adjust the WSDL manually by replacing "xsd:base64Binary" by
> "xmime:base64Binary" with xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
> then SoapUI generates the correct SOAP request from it!
>
> Can I configure the WSDL generation so that it puts "xmime:base64Binary"
> into the WSDL? Or is it a bug in servicemix-jsr181 or even XFire?
>
> Thanks for your help...
>
> André
>
>
--
View this message in context: http://www.nabble.com/wrong-WSDL-generated-for-MTOM-attachments-tf4354339s12049.html#a12776613
Sent from the ServiceMix - User mailing list archive at Nabble.com.