I reached the same conclusion. I'm surprised that the MtoM stuff works
at all on wrapped parameters. The only difference is that I've taken a
vow to use BARE services when I care to know exactly what is going on.

On Tue, 2008-01-15 at 11:05 +0000, Ian Roberts wrote:
> Benson Margulies wrote:
> > Thank you. 
> > 
> > I wonder if it's a bug in CXF that the JavaFirst trick doesn't work? Or
> > is there an @XmlElement trick to specify base64Binary for the string?
> 
> I got exactly the same behaviour from Metro.  I think the only way to do 
> it is to write the request wrapper class yourself.
> 
> @WebMethod
> @RequestWrapper(className = "my.service.MTOMStringRequest)
> public String myMethod(@WebParam(name = "param") String param);
> 
> 
> 
> @XmlAccessorType(XmlAccesType.FIELD)
> @XmlType(name = "mtomStringRequest")
> public class MTOMStringRequest {
> 
>    @XmlElement
>    @XmlSchemaType(name = "base64Binary")
>    @XmlMimeType("text/plain")
>    protected String param;
> 
>    // getter and setter for param here
> }
> 
> Unfortunately you can't put @XmlSchemaType directly on a method parameter.
> 
> > 
> > On Mon, 2008-01-14 at 16:15 +0000, Ian Roberts wrote:
> >> Benson Margulies wrote:
> >>> I want to use MtoM to ship non-XML-1.0 text. So, I'd just as soon
> >>> declare String properties, not DataHandlers. Does anyone know if this is
> >>> likely to work? 
> >> It should work if you're going WSDL-first - define your element as type 
> >> xsd:base64Binary and add xmime:expectedContentType="text/plain". 
> >> Starting from Java it didn't quite work for me.  With:
> >>
> >> String myMethod(@XmlMimeType("text/plain") String myParam)
> >>
> >> the generated schema had the xmime:expectedContentType on myParam but 
> >> the element type was still xsd:string, so not MTOM-able.  It may be more 
> >> successful if you write your own RequestWrapper class with annotations 
> >> to force the type to xsd:base64Binary, but I gave up at that point and 
> >> just made my parameters byte[] instead (the tools I'm passing the data 
> >> on to are equally happy with an InputStream as with a StringReader).
> >>
> >> Ian
> >>
> > 
> 
> 

Reply via email to