Kishore, This turns out to be the exact solution that I require. I just extended AxisServlet and scrape off the "requestURL" which is the URL that was used to reach the WS. That did the trick.
<offTopic> And again, this illustrates what I consider a flaw in the Axis implementation. If you look through the Axis source code they drag the HTTP Request right to the door step of the dispatcher and then choose to NOT pass it along to the dispatched method. I am not sure why. Surely access to the request would benefit some WS methods. Oh well. </offTopic> Thanks for all of the input. I got a lot of help from this group. Sorry to have taken up so much bandwidth. --Marty --- Kishore Senji <[EMAIL PROTECTED]> wrote: > On Thu, 27 Jan 2005 21:17:07 -0800 (PST), Martin Wegner > <[EMAIL PROTECTED]> wrote: > > David, > > > > Also, as I said early the Axis architecture is such that it does not > > provide any of the information related to the HTTP layer beneath SOAP. > > The only think you know is that your dispatcher gets called. So my > > problem may be considered a limitation in Axis. > > > > Assuming that all your web service requests to Axis contains /axis in > the path for eg(http://company.com/axis/WebService.jws), I guess you > could have a Filter for the url-pattern /axis/* whose job is to take > the path that was requested (eg > http://company.com/axis/WebService.jws) and stick it into your > business objects? Essentially having a Filter instead of a Plugin. So, > when a web service is requested, before the request reaches the > AxisServlet, the Filter would save the URL in the business objects and > your business objects can throw that URL into the response. Wouldn't > this work? > > --Marty > > > > > Martin, since you seem firm on this issue, can we/I ask WHY you need > > > this > > > information in your webapp during initialization? What are you > doing > > > that > > > you cannot set that information per request (HTTP/SOAP) in your > output? > > > (Or > > > use relative URLS of some sort) Knowing WHY, perhaps someone on the > list > > > can > > > suggest an alternate, yet equally effective, solution for the issue. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
