Tomek, Thanks for the reply about using the client, that appears to have worked nicely! I was able to easily transfer files that I turned into byte arrays and sent over the wire to the service. Obviously however, reading an entire file into a byte array first isn't wise (or neccessarily possible) for really large files, ideally, you would like to stream the file in from the file into the attachements as you send the web service requests (and likewise stream the output to an output file on the server side). I believe this is the idea of using the DataSource, so I set about to try this example, however, I appear to have a problem.
Here is my service function (just added a file to save the incoming bytes to): public boolean mtomDataSource(DataSource ds, String ftpSrvrPath) throws RemoteException; However, when I generate the stubs for this, I just get a byte[] signature for the client ( client.mtomDataSource(byte[], String)), so it won't let me use a DataSource in the signature. Here's the generated WSDL (bits that are important) <wsdl:operation name="mtomDataSource"> <wsdl:input name="mtomDataSourceRequest" message="tns:mtomDataSourceRequest"/> <wsdl:output name="mtomDataSourceResponse" message="tns:mtomDataSourceResponse"/> <wsdl:fault name="RemoteException" message="tns:RemoteException"/> </wsdl:operation <xsd:element name="mtomDataSource"> <xsd:complexType> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="in0" nillable="true" type="xsd:base64Binary"/> <xsd:element maxOccurs="1" minOccurs="1" name="in1" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> What have I done wrong and is my assumption about using the DataSources to transfer data without having to hold it all in memory correct? Thanks again! Nate ----- Start Original Message ----- Sent: Tue, 31 Oct 2006 13:20:47 +0100 From: "Tomek Sztelak" <[EMAIL PROTECTED]> To: [email protected] Subject: Re: [xfire-user] MTOM/Client issues > You can set properties in the same way as on dynamic client :) > > WebTransferClient service =3D new WebTransferClient(); > WebTransferPortType client =3D service.getWebTransferPortTYpe(); > Client soapClient =3D Client.getInstance(client); > soapClient .setProperty("mtom-enabled", "true"); > soapClient .setProperty(HttpTransport.CHUNKING_ENABLED, "true"); > > > On 10/31/06, Nate Woody <[EMAIL PROTECTED]> wrote: > > All, > > > > Forward apologies for a stupid question. We have several xfire services th= > > at we have developed and are now interested in using the MTOM for sending l= > > arge amounts of data. The server side code is simple enough and we impleme= > > nted that first. Looking at the client code however, we see this: > > > > Service serviceModel =3D new ObjectServiceFactory() > > .create(MTOMService.class, > > "MTOMService", > > "http://xfire.codehaus.org/MTOMService";;, > > null); > > > > MTOMService service =3D (MTOMService) new XFireProxyFactory() > > .create(serviceModel, "http://localhost:8080/mtom/services/= > > MTOMService"); > > > > // Setup properties > > Client client =3D Client.getInstance(service); > > client.setProperty("mtom-enabled", "true"); > > client.setProperty(HttpTransport.CHUNKING_ENABLED, "true"); > > > > However, this requires having the service class available in order to work.= > > We typically generate the stubs from the wsdl for our clients and so end = > > up with three classes like (Given a service named WebTransfer): > > > > WebTransferClient > > WebTransferImpl > > WebTransferPortType > > > > which we use like this: > > > > WebTransferClient service =3D new WebTransferClient(); > > WebTransferPortType client =3D service.getWebTransferPortTYpe(); > > client.sendDataByDataSource(dataSource); > > > > My long winded question then is how do we set the mtom-enabled and other pr= > > operties when we are generating the classes from a remote wsdl? Is that av= > > ailable from the standard way we have been calling the classes, or do we ne= > > ed to be using Factory methods in some way, that I haven't been able to fin= > > d documentation for? > > > > Thanks, > > Nate > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > -- > ----- > When one of our products stops working, we'll blame another vendor > within 24 hours. > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > ----- End Original Message ----- --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
