Nige,
Axis supports handlers that can get at the SOAP request and response on the way out and on the way back. It supports this on the client and server sides. You just have to configure the client and server side WSDD files and supply classes for the handlers. Axis calls the invoke method of each handler and passes the message context. Most or all of the information related to a single request/response is accessible from the message context. Handlers are often used to add and process SOAP headers, though they don't have to.
If the first call results in a hand-off of the request, to another URL, a handler, in the response chain of the server side, can add that URL (it can be obtained from the HTTP request object, if you don't have it any other way) in a SOAP header (that you define) to the SOAP response. A client side handler, in the response chain, can remove the information from the header and store the information somewhere. If you're using a single Call object, you may be able to update the endpoint in that object, in which case all subsequent requests should go to the new endpoint. Alternatively, I believe that the endpoint is ultimately stored in the message context and retrieved from there by the HTTP sender, so a request chain handler could pick up the previously stored endpoint (if there is one) and update the one stored in the message context.
This is all off the top of my head and I've never tried any of this but it doesn't seem like too much work and may be optimized if you can determine whether a call is the first call for a client (to avoid creating and sending the header with each response). The client handler class could be combined with the client jar file, along with a client-config.wsdd file.
You might also be able to change the HTTP transport chain, I think, and so extend the Axis HTTPSender class to perhaps respond to a 301, adding the new URL to a mapping of logical and actual URLs, using the real URL for each outward request.
Tony
"Nige White" <[EMAIL PROTECTED]> wrote on 02/12/2004 15:22:10:
> [EMAIL PROTECTED] wrote:
>
> Have you thought about SOAP headers? The first response could
> include a header giving a new URL for subsequent calls. On the
> client, a handler could check for the header and, if present, store
> the value as the endpoint address. You could probably work out how
> to then modify the Service object or update the URL in the message
> context for each call. I'm sure there is a way to handle this
> without modifying the stub or doing any TCP/IP programming.
>
> So I'd have to write an implementation of some kind of plugable
> interface that Axis offers to change its functionality, and provide
> this along with the WSDL of our service so that the programmers on
> the client side can plug it in?
>
> Any idea what interface would do this? I could just extend the Axis
> default implementation if I knew what it was.
>
> Apache Soap follows the redirect, but it does it for every request
> instead of seeing that 301 means moved *permanently* and changing
> its endpoint accordingly! So it's getting a brand new server for
> each call, which obviously isn't logged in and initialized.
>
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : [EMAIL PROTECTED]
>
- Re: How to get/set cookies from the Axis *client* side? tony . q . weddle
- Re: How to get/set cookies from the Axis *client* s... Tim K. (Gmane)
- Re: How to get/set cookies from the Axis *clien... tony . q . weddle
- Changing the endpoint by sending redirects from... Nige White
- Re: Changing the endpoint by sending redire... Nige White
- Re: Changing the endpoint by sending redire... tony . q . weddle
- Re: Changing the endpoint by sending redire... Nige White
- Re: Changing the endpoint by sending redire... TMG
- Re: Changing the endpoint by sending redire... Nige White
- Re: Changing the endpoint by sending redire... TMG
- tony . q . weddle