message-style frustrations (this time in plain text)

["Volkmann, Mark" <Ma...@AGEDWARDS.com>]

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.

------------------------------------------------------------------------------------------

Re: message-style frustrations (this time in plain text)

[remko de knikker <re...@yale.edu>]

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.
>
> ------------------------------------------------------------------------------------------