2010-06-25 8 views
2

Je rencontre un problème plutôt frustrant en essayant d'appeler un service Web qui nécessite une pièce jointe.Appelez le service Web avec pièce jointe

C'est l'erreur:

Unexpected Attachment type =class java.lang.Object

d'ici:

class="com.sun.xml.ws.client.sei.ResponseBuilder$AttachmentBuilder" file="ResponseBuilder.java" line="250" method="createAttachmentBuilder"

La méthode du proxy Web me donne est la suivante:

public Reply putDocument(
    @WebParam(targetNamespace="uri:put.document", partName="request", name="request") 
     StoreType request, 
    @WebParam(targetNamespace="", partName="put", name="put") 
     Object put); 

Ce que je ne peux pas comprendre est ce que passer à "put", qui est seulement défini comme un objet.

J'ai essayé:

byte[] 
String 
DataHandler(ByteArrayDataSource) 
uri.put_document.ObjectFactory.createPut(byte[]) 
AttachmentPart 

J'ai aussi essayé de chercher le code, mais ne l'ai pas eu la chance jusqu'à présent.

EDIT: WSDL est la suivante.

<?xml version="1.0" encoding="UTF-8" ?> 
<definitions targetNamespace="urn:fer" 
      xmlns="http://schemas.xmlsoap.org/wsdl/" 
      xmlns:tns="urn:fer" 
      xmlns:get="uri:get.document" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
      xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
      xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"> 
    <types> 
     <xsd:schema> 
     <xsd:import namespace="uri:get.document" 
        schemaLocation="../xsd/getDocument.xsd"/> 
     </xsd:schema> 
    </types> 
    <message name="putDocument"> 
    <part name="request" element="put:request"/>  
    <part name="put" element="put:put"/> 
    </message> 
    <message name="putDocumentReply"> 
    <part name="reply" element="put:reply"/>  
    </message> 
    <portType name="FrontEndRepository"> 
    <operation name="putDocument"> 
     <input message="tns:putDocument"/> 
     <output message="tns:putDocumentReply"/> 
    </operation> 
    </portType> 
    <binding name="frontEndRepositoryPortSOAP11Binding" 
      type="tns:FrontEndRepository"> 
    <soap:binding style="document" 
        transport="http://schemas.xmlsoap.org/soap/http"/> 
    <operation name="putDocument"> 
     <soap:operation style="document" 
         soapAction="putDocument"/> 
     <input> 
     <mime:multipartRelated> 
      <mime:part> 
      <soap:body use="literal" parts="request"/> 
      </mime:part> 
      <mime:part> 
      <mime:content part="put" type="binary"/> 
      </mime:part> 
     </mime:multipartRelated> 
     </input> 
     <output> 
     <soap:body use="literal"/> 
     </output> 
    </operation> 
    </binding> 
    <service name="FrontEndRepository"> 
    <port name="FrontEndRepository" 
      binding="tns:frontEndRepositoryPortSOAP11Binding"> 
     <soap:address location="http://localhost:7101/FER-FrontEndrepository-context-root/frontEndRepositoryPort"/> 
    </port> 
    </service> 
</definitions> 
+0

Nous avons besoin de votre WSDL. Regardez aussi ici https://jax-rpc.dev.java.net/whitepaper/1.1.2/attachments-howto.html –

+0

@Romain: WSDL ajouté. Merci! –

+0

Pouvez-vous lui transmettre une valeur nulle ou une ficelle String? Toute instance Serializable non-Object semble avoir du succès. –

Répondre

2

Je m'attends à ce que l'attribut type de l'élément mime: content contienne un type MIME, par exemple. "application/octet-stream", "application/pdf" ou "text/plain" plutôt que "binary". En utilisant javax.activation.DataHandler devrait fonctionner, et je pense que vous devriez être en mesure de réparer le type MIME de la pièce jointe, puis utiliser une instance DataHandler ou un type approprié au type MIME (par exemple, java.awt.http: //www.javax.activation.org/data/index.html). Image pour "image/jpeg").

Vous dites que vous avez essayé un DataHandler, mais vous n'avez pas fourni l'exception pour ce cas. Si cela échoue encore, que se passe-t-il lorsque vous l'essayez?

+0

Je reçois la même erreur dans tous les cas. –

+0

L'erreur était survenue lors du chargement de la définition de service, et non lors de l'invocation de l'opération. Donc, ceci devait être corrigé pour toutes les définitions dans le WSDL. –