Glen's question about method signatures (included below) touches on 
something that has confused me about Axis.

Where are these method signatures defined?  That is, where in the API 
documentation or user's guide or whatever do I look to find out what Axis 
will hand me under what circumstances?  I'm working from code I found in 
the samples/message directory, and that version of a messaging service has 
this signature:

public Element[] myMethod(MessageContext msgC, Vector elems)

meanwhile, the samples/proxy service uses:

public Document myMethod(MessageContext msgContext)

and the example Glen cites uses:

public void myMethod(MessageContext context, Document doc).

Under what circumstances will Axis hand stuff to my code in these different 
forms?  Does it figure out from my exposed methods which form to give me, 
or is that specified in the deployment descriptor?  Currently I get an 
Element[] array and MessageContext and return an Element[] array, which is 
fine; I just need to understand what the other options are, which I 
"should" be using, and why.

A related question: what are the different ways of writing messaging 
clients?  I see from the samples/message example that I can use the Call 
class and invoke() the service with an array of SOAPBody elements; any 
other ways?

Maybe this is infeasible because everyone's doing something different with 
Axis, but I would welcome a section in the Axis User's Guide that outlines 
the main "consumer" classes and methods that are likely to be used in:

1) a basic RPC client
2) a basic RPC sevice
3) a basic messaging client
4) a basic messaging service.

Otherwise, there's so much to look at in the Javadocs that you don't really 
know where to start.  It sounds like WSDL2Java makes good sample code, but 
if you're trying to write a client/server combo and learn WSDL at the same 
time, it's easy to get lost.

Andrew


>Is anyone currently using the method signatures with the MessageContext 
>argument on document-style services with the MsgProvider?  e.g.:
>
>public void myMethod(MessageContext context, Document doc)
>
>I am planning to remove this functionality over the weekend.  Please 
>switch to using MessageContext.getCurrentContext() if you haven't already.



Reply via email to