Hi
Volkmann,
Regarding the
third method signature (passing document), this is how its works for
me...
Service service
= new Service();
Call call =
(Call) service.createCall();
String endpoint = "http://myEndpoint"; // give your end
point here
call.setTargetEndpointAddress(new
java.net.URL(endpoint));
// creating a Document object from person.xml file
DOMParser parser = new
DOMParser();
parser.parse("person.xml");
Document document = parser.getDocument();
// add your document to SOAPBodyElement and call invoke passing
SOAPBodyElement.
//
though your service method expects a
document, this is the way you should pass document because you cannot embed a
document in another document since SOAPEnv is itself a
document.
SOAPBodyElement[] input = new
SOAPBodyElement[1];
input[0] = new
SOAPBodyElement(document.getDocumentElement());
Vector rVec = (Vector)call.invoke(new Object[]{input[0]});
And in your server-config.wsdd file, for your service change
provider="java:MSG" or put style="message".
Hope this helps...
Cheers,
Ranjith.
-----Original
Message-----
From: remko de
knikker [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2003 7:55
AM
To:
[EMAIL PROTECTED]
Subject: Re: message-style frustrations
(this time in plain text)
Take a look at
http://biryani.med.yale.edu:8081/axis/index.jsp?which=6
there
is some code for each service available.
Volkmann, Mark
wrote:
I'm trying to learn how to use message-style services
in Axis. The documentation says that a message-style service can have
any of the following method signatures.
public Element [] method(Element [] bodies);
public
SOAPBodyElement [] method (SOAPBodyElement [] bodies);
public Document method(Document body);
public void
method(SOAPEnvelope req, SOAPEnvelope resp);
In the samples/message directory there is
an example that demonstates using the first of these signatures. Oddly
the client code (TestMsg.java) passes it SOAPBodyElement objects instead of
org.w3c.dom.Element objects and it works anyway. Why is
that?
Based on my attempts to get all four signatures to
work, it seems that each service class can only use ONE of these
signatures. Can someone confirm that restriction?
Also, I think there's a reason why the sample only
demonstrates the first signature. I don't believe the others work!
I'd love to be proven wrong on this with working examples that could be added
to the samples directory.
I'm mostly interested in getting the third signature
(Document) to work. Here's a description of what I tried and the
results.
Without making any extra calls on the Call object
before the call to the invoke method I get "No operation name
specified!". That's odd because the sample doesn't specify an operation
name for the first signature and it works.
When I set the operation name on the Call object with
call.setOperationName(myServiceMethodName) I get back a String instead of a
Document. The value of the String is the value of the first Text node in
the Document that the service returned, not the whole
document.
I decided to specify the parameter and return types on
the Call object as Document using the following code.
QName docQName = new QName("http://dom.w3c.org/Document", "Document");
call.addParameter("doc", docQName, Document.class,
ParameterMode.IN);
call.setReturnType(docQName,
Document.class);
This time I got a SAXException on the client side that
said "could not find deserializer for type {http://dom.w3c.org/Document}Document". The part in the
curly braces is the namespace I assigned to the parameter and return
types. I'm real unsure about how I should have created that QName
object.
Next I explicitly set the operation style on the Call
object to "message" with call.setOperationStyle("message"). This time I
got back the correct data, but it was in a SOAPBodyElement object instead of a
Document object.
Please let me know if you have successfully used the
Document signature for a message-style service and if possible send me an
example.
Thanks!
------------------------------------------------------------------------------------------
A.G. Edwards & Sons' outgoing and incoming e-mails are
electronically
archived and
subject to review and/or disclosure to someone other
than the
recipient.
------------------------------------------------------------------------------------------
