Andreas,
Thanks for the explanation and it was good indeed for my understanding. i am
now trying SwA to do the same. I have one question, I have a service that
has DataHandler return type. Now when the service is invoked from the client
end, in the server side I am adding an attachment to the MessageContext like
this:
OperationContext operationContext = getOperationContext();
MessageContext outgoingMsg =
operationContext.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
outgoingMsg.addAttachment(attachment.getContentType(), attachment);
The service is also returns a datahandler. So basically I am returning a
DataHandler as well as sending the same datahandler as an attachment (SwA).
Is it possible to do so? Right now I am getting following exception when I
try to invoke the service in the client end:
org.apache.axis2.AxisFault
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:90)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:353)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:416)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
Caused by: java.lang.NullPointerException
at
org.apache.axis2.builder.BuilderUtil.createAttachmentsMap(BuilderUtil.java:505)
at
org.apache.axis2.builder.MIMEBuilder.processDocument(MIMEBuilder.java:38)
at
org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:164)
at
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:112)
at
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:88)
... 49 more
I have following code in the client to invoke the service:
options.setProperty(Constants.Configuration.ENABLE_SWA,
Constants.VALUE_TRUE);
options.setProperty(Constants.Configuration.CACHE_ATTACHMENTS,
Constants.VALUE_TRUE);
options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
ServiceClient sender = new ServiceClient();
OperationClient mepClient =
sender.createClient(ServiceClient.ANON_OUT_IN_OP);
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace ns = fac.createOMNamespace("http://www.abc.com/webservice";,
"ns");
MessageContext mc = new MessageContext();
SOAPEnvelope env = createEnvelope(ns, argNameList, args);
mc.setEnvelope(env);
for (int i = 0; i < attachmentList.size(); i++) {
DataHandler dh = (DataHandler) attachmentList.get(i);
mc.addAttachment(dh.getName(), dh);
}
try {
mepClient.setOptions(options);
mepClient.addMessageContext(mc);
mepClient.execute(true);
} catch (Exception e) {
e.printStackTrace();
}
Chinmoy
On Fri, Mar 27, 2009 at 4:37 AM, Andreas Veithen
<[email protected]>wrote:
> Chinmoy,
>
> I would say that in the case of MTOM (SwA is different), it is
> conceptually incorrect to assume that the DataSource name and content
> type are preserved when the message is sent over the wire. The reason
> is that MTOM defines a transformation between two different
> representations of the same information model: one that encodes binary
> data as base64 stored in a text node and one that encodes binary data
> as MIME parts. Since in the first representation the name and content
> type are unspecified, it would be wrong to assume that they are
> meaningful in the second representation (otherwise the representations
> would not be equivalent). In MTOM, content types (for the binary data)
> only appear because the message format is MIME, which uses content
> types. I guess that if the people who developed the MTOM specs had
> decided not to use MIME, they would not have introduced the concept of
> content types.
>
> Andreas
>
> On Thu, Mar 26, 2009 at 14:13, Chinmoy Chakraborty <[email protected]>
> wrote:
> > Andreas,
> >
> > Thanks for your reply. Actually I am trying to invoke a service which
> > returns a DataHandler through MTOM. I have following code in the service
> > class:
> >
> > FileItem file = (FileItem) value;
> > ByteArrayDataSource bads = new ByteArrayDataSource(file.getInputStream(),
> > "application/msword");
> > bads.setName("abc.doc");
> > return new DataHandler(bads);
> >
> >
> > So far so good. The newly created DataHandler preserve the name. I have
> > following code in the client end from where I am invoking the service:
> >
> > ServiceClient sender = new ServiceClient();
> > sender.setOptions(options);
> > OMFactory fac = OMAbstractFactory.getOMFactory();
> > OMNamespace ns =
> > fac.createOMNamespace("http://www.abc.com/webservice";, "ns");
> > OMElement payload = createPayload(ns, argNameList, args);
> > OMElement retVal = sender.sendReceive(payload);
> > if (retVal != null) {
> > OMElement ele = retVal.getFirstElement();
> > OMText binaryNode = (OMText) ele.getFirstOMChild();
> > binaryNode.setOptimize(true);
> > return (DataHandler) binaryNode.getDataHandler();
> > }
> >
> > I am trying to return a .doc file. When I receive the datahandler in the
> > client end DataHandler#getName() returns "MyByteArrayDataSource" and the
> > content type becomes "application/octet-stream" meaning binary.
> >
> > Hope I made you understand the problem. May be the code
> > "binaryNode.setOptimize(true);" made the content-type binary. Then how to
> > get a .doc or other file type?
> >
> > Chinmoy
> >
> >
> >
> >
> >
> > On Wed, Mar 25, 2009 at 1:29 PM, Chinmoy Chakraborty <[email protected]>
> > wrote:
> >>
> >> Hi All,
> >>
> >> I noticed DataHandler.getName() always returns 'MyByteArrayDataSource'
> if
> >> the data source is ByteArrayDataSource from which the DataHandler has
> been
> >> created. Please look at the code below:
> >>
> >> FileItem file = (FileItem) value;
> >> ByteArrayDataSource bads = new
> ByteArrayDataSource(file.getInputStream(),
> >> "application/msword");
> >> bads.setName("abc.doc");
> >> DataHandler dh = new DataHandler(bads);
> >>
> >> Now if I do, dh.getName(), it always returns 'MyByteArrayDataSource". I
> >> guess this is a bug. Whats your opinion?
> >>
> >>
> >> Chinmoy
> >
>
