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
--
Ian Roberts | Department of Computer Science
[EMAIL PROTECTED] | University of Sheffield, UK
