A Devil's Advocate says: I agree with the theory that the webapp Context name within the application server "/myapp" should be available to the servlet but not the host/port/etc. Why? Imagine you work on a project like mine where you are using virtual host capability to map various paths on various virtual hosts to your one Java webapp (one instance for all clients). The startup information you would obtain, in that situation, on the host and server port would be wrong. Only the request object would have the correct data.
With that in mind, the Devil's Advocate suggests: Can you provide a plug-in to check a file for the information you require? On first run, there would be no data so let them, upon first installation, run an action. That action could see if said file exists and, if not, put it's url information (from the request) into that file (and this one time into that class's class instance data). If the file exists, the action could politely return a page explaining the requested function is not available (to prevent someone from potentially screwing things up by running that action again). Regards, David, the devil's advocate today. -----Original Message----- From: Martin Wegner [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 12:53 PM To: Struts Users Mailing List Subject: RE: PlugIn and the base URL Agreed. That approach works more often than not. Except in this case. The client of the WS does indeed use the URL that is sent back. That is part of the overal protocol. So it has to be a valid URL that reaches the WS inside of my Struts app. One could argue that the real problem is within Axis, which does not provide any HTTP details to the WS call dispatcher. If I had access to that info I could stuff it into the WS DOM response and not bother with the Struts PlugIn. Sigh. --Marty --- "Varley, Roger" <[EMAIL PROTECTED]> wrote: > > > > The WS response has to contain the URL that was used to > > access the WS. > > This is a requirement of the XML Schema that defines the WS response > > payload. I have no control over this. > > > > I know this might be stupid, but whenever I see an odd requirement like > this my first experiment is to see what happens if I pass something that > is a valid URL but doesn't actually point anywhere. In this way you > could simply "hard-code" a string value into your plugin. It wouldn't be > the first time I've come across a "mandatory" requirement that doesn't > actually do anything :) > > Regards > Roger --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
