When I generate new web service via the wizard, the wsdl it generates does not contain the following piece which I have modify: <mime:multipartRelated > <mime art > <wsdlsoap:body use="literal"/> </mime art> <mime art> <mime:content part ="requestAttachmentReturn" type= "application/pdf"/> </ mime art> </mime:multipartRelated>
So, then I attempt to test my service and I recieve the following exception when the actual call is made:
faultCode: Server.generalException faultString: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.MarshalException: CORBA MARSHAL 0x4942f896 No; nested exception is: org.omg.CORBA.MARSHAL : Unable to read value from underlying bridge : null vmcid: IBM minor code: 896 completed: No
I presume you've given this a go to create an example that works and then incrementally modify it toward a version that is useful to you? SOAP attachments with JAX-RPC
Joined: Feb 21, 2006
That is correct. I have followed that exact example. The only difference, my Datahandler is an output of my service vs its input.
So, the service itself is responsible for looking up a pdf file and wrapping it into a DataHandler object which is then sent back.
Is there something I am missing?
Joined: Aug 19, 2005
The fact that it doesn't generate the MIME element in the WSDL is disturbing. It leads me to believe that the wizard can't deal with the javax.activation.DataHandler as the return type of the endpoint interface. The DataHandler return type must be represented in some way in the WSDL.
If you went WSDL2Java (I believe the article used this path), WebSphere may allow you to specify a JAX-RPC Mapping file that may get the point across
That is correct. There are two files I had to apply changes to manually once the wizard generated all the appropriate files for the new web service:
1) The MyEJB.wsdl file had to be changed to change the return type as hexBinary and specify content type as application/pdf. ... <element name="requestPDFResponse"> <complexType> <sequence> <element name="requestPDFReturn" nillable="true" type="xsd:hexBinary"/> </sequence> </complexType> </element> ... <mime:multipartRelated> <mime art> <wsdlsoap:body use="literal"/> </mime art> <mime art> <mime:content part="requestAttachmentReturn" type="application/pdf"/> </mime art> </mime:multipartRelated>
2) I changed the MyEJB_mappings.xml file as well to reflect the return type which is now a byte as its class type and also to specify the return value which is the DataHandler. I actually tricked it a bit in order for WSAD to regenerate the mapping for me. Basically, once I manually changed the above wsdl file with the content type changes, I did a Web Service->Generate Java Bean Skeleton. It is then recreated for me the mappings file. ... <java-xml-type-mapping id="JavaXMLTypeMapping_1140546093755"> <class-type>byte</class-type> <root-type-qname id="RootTypeQname_1140546093755"> <namespaceURI>http://www.w3.org/2001/XMLSchema</namespaceURI> <localpart>hexBinary</localpart> </root-type-qname> <qname-scope>simpleType</qname-scope> </java-xml-type-mapping> ... <method-return-value>javax.activation.DataHandler</method-return-value> <wsdl-message id="WSDLMessage_1140546093755"> <namespaceURI>http://myspace</namespaceURI> <localpart>requestPDF</localpart> </wsdl-message> ....
I can send you my full wsdl file, as well as the mappings file if you like to take a look at.
So, I am kind of stuck at this point... Also, I am curious, DataHandler object is obviously NOT serializable. So, I am not sure does that mean it can not be sent across and we need to write our own serializable wrappers for it but all the examples on the web that show the SOAP attachment, just simply pass the DataHandler. So, I guess I am a bit confused at that part. Also, WSAD flags that fact as well...
Joined: Aug 19, 2005
Originally posted by Costanza Smith: ... MyEJB.wsdl...
You are using an EJB service endpoint? That makes me wonder...I don't recall that there are any guarantees that an EJB service endpoint supports the full functionality supported by a JAX-RPC service endpoint (JSE). EJB service endpoints are handled by the EJB Container while JSEs operate out of the Servlet Container using the JAX-RPC runtime. And attachments are a special SAAJ/JAX-RPC feature.
I don�t think the DataHandlers are serializable as such but JAX-RPC is supposed to know how to use their interface to stream them to and from MIME parts.
You may want to try if you can get it to work as a JSE. Even if EJB service endpoints can�t handle attachments directly you may be able to use attachments by installing a SOAP handler. The handler would use the SAAJ API to strip off any incoming attachments and place them in the current javax.xml.rpc.MessageContext. Inside the endpoint the MessageContext can be retrieved through the endpoint's javax.ejb.SessionContext getMessageContext() method. Outgoing attachments could be placed in the MessageContext, so that the SOAP handler can build a MIME envelope around the outgoing response.
This suggests however that attachments/DataHandlers are supported by EJB Service Endpoints in WebSphere.
You may also want to experiment with a .jpg file rather than a .pdf file. FileDataSource relies on the mimetypes.default registry file. That file should have a mapping for JPEGs but it may not have the "application/pdf pdf PDF" mapping - in which case it will use the "application/octet-stream" MIME type. Once you get it working for a JPEG you can add your own mime.types file which includes the pdf mapping. [ February 22, 2006: Message edited by: Peer Reynders ]
so how exactly can make a webservice return a datahandler?
i created a webservice that it's input is a datahandler and it works fine but when i set the output in the wsdl to be a datahandler the function signature is generated as void!!
I have created a webservice that accepts a DataHandler  parameter and an xml string with meta data regarding the files in the handler, however, i get this error message when the message hits the endpoint:
Instead of re-opening more than one year old posts, you can do a fresh post and may refer the old post link into it. In that way, whoever is trying to read your post might not go through unrelated content.
(OCEEJBD6, SCWCD5, SCDJWS, SCJP1.4 and Oracle SQL 1Z0-051)