I would personally couple this with the thread idea I mentioned earlier... Spawn a thread to send through a request after a few seconds to check baseURL or set it as appropriate. That would remove the user interaction aspect, and probably would get everything set up quicker, at least in a known amount of time.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, January 26, 2005 1:52 pm, Wiebe de Jong said: > Hey David, that is a great idea. > > Let me build on it a bit... > > When the .war file is deployed, the baseURL property will be blank. > > When the application starts up, it will check this property. If the > property > is blank, the app will be in 'inactive' state and the only menu item > presented to the user is 'Activate'. The action for 'Activate' will read > the > URL from the response and set the property. The application is now in the > 'active' state and operating normally. > > The next time the application starts up and checks the property, it is not > blank so the app is 'active'. > > The activate action could do a couple of other things as well, such as > record the activation time (if you need it for billing) or fire off a > message to a licensing or billing server (for hosted apps, etc). > > Wiebe de Jong > > > -----Original Message----- > From: David G. Friedman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 26, 2005 10:33 AM > To: Struts Users Mailing List > Subject: RE: PlugIn and the base URL > > 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] > > > --------------------------------------------------------------------- > 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]
